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Hoofdstuk 1 


Inleiding 


1.1 Waarom simuleren 


Iedereen heeft in zijn/haar leven te maken met (het oplossen van) problemen. 
Problemen treden in het algemeen op als gevolg van (impliciet) gestelde doe- 
len, welke tevens de gewenste oplossing van het probleem aangeven. Sommige 
problemen kunnen ‘direct’ opgelost worden; de oplossingen zijn bekend. Bij- 
voorbeeld het probleem van een ‘lekke fietsband’ (zie linker tak figuur 1.1). 

Andere problemen lijken of zijn nieuw. Bij het zoeken naar een oplossing 
hiervan kan en moet men soms gebruik maken van modellen (dat wil zeggen 
vereenvoudigde voorstellingen van de werkelijkheid) van de systemen waarin 
de problemen zich voordoen. 

Door het gebruik van modellen wordt het mogelijk een stuk werkelijkheid 
en eventuele veranderingen van die werkelijkheid te bestuderen zonder dat 
een (ongewenste) ingreep in die werkelijkheid nodig is. Bijvoorbeeld onderzoek 
naar de optimale opstelling van machines in een produktiehal. 


Indien het gedrag van een systeem met betrekking tot een probleem goed 
beschreven kan worden met behulp van wiskundige vergelijkingen die men 
exact of benaderd kan oplossen dan zal men veelal wiskundige modellen toe- 
passen. Denk bijvoorbeeld aan de bewegingen van macroscopische voorwerpen 
met behulp van de wetten van de mechanica, de econometrische modellen van 
het centraal planbureau of de diverse wiskundige modellen uit de operations 
research. Voor een aantal probleemsituaties kan dit (nog) niet of zou dit te veel 
tijd en/of geld kosten. Bijvoorbeeld voor het bepalen van geschikte prioriteits- 
regels voor het in bewerking nemen van orders in een zogenaamde job-shop 
(Baker & Bertrand 1981). 

In dergelijke situaties kan men van de te beschouwen systemen vaak wel 
een simulatiemodel maken. 


Onder een simulatiemodel verstaan we een zodanige beschrijving van 
de componenten van een systeem en hun onderlinge relaties dat op grond 
hiervan het gedrag van het systeem (in de tijd) nagebootst kan worden. 
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Figuur 1.1: Het oplossen van problemen 


Voorwaarden voor het kunnen maken van zo’n (simulatie)model is dat er 
een concrete doelstelling geformuleerd is en dat de voor het probleem essentiële 
eigenschappen van de systeemcomponenten kwantificeerbaar zijn. Voor het be- 
grip simulatie zullen we de volgende definitie hanteren (gebaseerd op Shannon 


1975): 


Simulatie is het proces om van een reëel systeem een simulatiemodel te 

ontwikkelen en met dat model experimenten uit te voeren om zodoende 

inzicht te krijgen in het (toekomstig) gedrag van dat systeem onder ver- 
_ schillende omstandigheden. 


Voor de volledigheid merken we op dat voor het oplossen van sommige 
problemen ook andersoortige modellen geschikt kunnen zijn; zie rechter tak 
figuur 1.1 (bijvoorbeeld het model van Bohr waarin de onderdelen van een 
atoom als harde bolletjes worden voorgesteld). 


Voorbeelden van toepassingen van simulatiemodellen zijn: 
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e (schaal)model van Zeeland om inzicht te krijgen in het stromingspatroon 
binnen de zeearmen, 

e CAD (computer aided design) modellen, bijvoorbeeld bij het ontwerpen 
van auto’s, kleding, de layout van een machinefabriek etc., 


Bij meer structureel gebruik van simulatiemodellen spreekt men wel van Be- 
slissings Ondersteunende Systemen (BOS) of Decision Support Systems (DSS). 
De hoofdcomponenten van dit soort systemen zijn: een modellenbank, een ge- 
gevensbank van de (input)gegevens voor de modellen en een mens-machine 
interface voor een flexibel gebruik van het systeem. 
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Figuur 1.2: Het oplossen van een probleem met behulp van computersimulatie 
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Wij zullen ons beperken tot simulaties op een computer (Pidd 1984, Law & 
Kelton 1982, Spriet & Vansteenkiste 1982, Swartz 1984, Neelamkavil 1987). 


Met betrekking tot het gedrag van simulatiemodellen in de tijd kunnen we 
een onderscheid maken tussen continu en discreet. 

Binnen een continu simulatiemodel verandert de toestand van een systeem 
continu. Typerend voor de beschrijving van het gedrag van de componenten 
is het gebruik van differentiaalvergelijkingen. Oorspronkelijk werd dit soort 
simulaties uitgevoerd op analoge computers. Later werden er technieken en 
hulpmiddelen ontwikkeld om het gedrag op digitale computers na te bootsen. 
Bij discrete simulatiemodellen verandert de toestand van het systeem op dis- 
crete tijdstippen; deze modellen zijn bij uitstek geschikt voor implementatie op 
digitale computers. Bij het modelleren van problemen op bijvoorbeeld bedrijfs- 
kundig, economisch, sociaal en technisch gebied kan het tijdsgedrag dikwijls 
discreet behandeld worden. We zullen ons verder tot dit soort systemen beper- 
ken. 

Binnen tal van systemen treden wachttijden (en wachtrijen) op, bijvoor- 
beeld bij kassa’s, machines, op verkeerswegen, bij verwerking van computer- 
jobs. Iedereen kent ze uit eigen ervaring. Daarom zullen we aan de hand van een 
eenvoudig wachtrijprobleem de in figuur 1.2 geschetste aanpak behandelen en 
toelichten. Het gaat daarbij om een tankstation met een beperkte wachtruimte 
waarbij men geïnteresseerd is in de wachttijden van klanten onder verschillende 
condities (een nadere omschrijving volgt in hoofdstuk 2). 


1.2 Aanpak 


Het oplossen van een probleem met behulp van computersimulatie is een cy- 
clisch proces waarin meer dan eens teruggekoppeld kan moeten worden (zie 
figuur 1.2). In dit proces kunnen een aantal fasen worden onderscheiden: de _ 
inductie-, de deductie- en de validatiefase. 

In de inductiefase vindt de feitelijke modelbouw plaats. In de deductiefase 
vooral het experimenteren met het model om tot een gewenste oplossing te ko- 
men. De ‘validatiefase’ verloopt parallel aan beide voornoemde fasen en betreft 
de activiteiten nodig om de geldigheid van het model te waarborgen. 

In hoofdstuk 2 komt na een korte, algemene behandeling van systemen en 
modellen het opstellen van een kwalitatief-beschrijvend of conceptueel model 
aan de orde. Samen met de gebruiker worden hierin de specificaties van het 
model vastgelegd. 

Bij de beschrijving van het gedrag van dit model in de tijd zijn meerdere 
uitgangspunten mogelijk: 


a. De activiteitenbeschrijving; een beschrijving van de afzonderlijke acti- 
viteiten met de voorwaarden waaronder deze optreden alsmede de er 
door veroorzaakte toestandsveranderingen van het systeem. 

b. De eventbeschrijving; het uitgangspunt daarbij is dat een beschrijving 
wordt gegeven van alle veranderingen van de toestand van het systeem 
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op de tijdstippen dat bepaalde gebeurtenissen (events) plaatsvinden. 

c. De procesbeschrijving; hierbij worden de toestandsveranderingen van een 
systeem beschreven vanuit de systeemcomponenten die de veranderingen 
veroorzaken. 


Voor laatstgenoemde beschrijvingswijze neemt de belangstelling steeds meer 
toe, ook bij het specificeren van ‘gewone’ informatiesystemen (Jackson 1983, 
Cameron 1986). De procesbeschrijving zal in de rest van dit boek centraal 
staan. Bij het specificeren van de procesbeschrijving zal een stroomschema- 
tekentechniek gebruikt worden. 

Om tot een kwantitatief model te komen moeten daarnaast de waarden 
van de benodigde parameters uit de te simuleren werkelijke situatie worden 
bepaald. 


Om inzicht te krijgen in het simulatieproces op implementatienivo zullen 
we in hoofdstuk 3 het tankstationsysteem eerst handmatig simuleren. 

In hoofdstuk 4 wordt ingegaan op de statistische aspecten van simulatie 
waaronder de betrouwbaarheid van simulatieresultaten. 

In hoofdstuk 5 zal worden nagegaan in hoeverre de verschillende kwanti- 
tatieve modellen met behulp van een programmeertaal als PASCAL kunnen 
worden geïmplementeerd op een computer. Het blijkt dat voor implementatie 
van procesbeschrijvingen talen zoals PASCAL minder geschikt zijn. 

Op procesbeschrijvingen geënt zijn de zogenaamde object-georiënteerde ta- 
len. In hoofdstuk 6 zal, als voorbeeld, de reeds ‘klassieke’ taal SIMULA beknopt 
behandeld worden. Vervolgens wordt de procesbeschrij ving van het tankstation 
in SIMULA vertaald. 

In hoofdstuk 7 wordt volgens de in dit boek behandelde methode uitgaande 
van de procesbeschijving, een wat uitvoeriger probleem tot in detail uitgewerkt 
en daarna geimplementeerd in SIMULA. 

In hoofdstuk 8 worden van een aantal opgaven uitwerkingen gegeven. 

Tenslotte volgt in hoofdstuk 9 een overzicht van de literatuur waarnaar in 
dit boek verwezen wordt. 

Het voorgaande vormt tevens een geschikte basis voor het gebruik van 
andere simulatietalen en simulatiepakketten. Binnen het kader van dit boek 
wordt hier verder geen aandacht aan besteed. 


1.3 Opgaven 


1 *Bedenk zelf enkele problemen die zich wel c.q. niet lenen om opgelost 
te worden met behulp van simulatie. O 


* (Van de opgaven voorzien van * is in hoofdstuk 8 een uitwerking opgenomen) 


N rk mT ae 4 a 
Ri e wid E 
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Systeembenadering en 
beschrijvingswijzen van discrete 
modellen 


2.1 Inleiding 


Voor het afbakenen en structureren van een probleem(gebied) zal gebruik ge- 
maakt worden van de systeembenadering. Deze systeembenadering is eveneens 
van belang voor het modelleren van het reële systeem. Het tijdsaspect van 
de zo verkregen discrete modellen kan op een drietal wijzen worden beschre- 
ven: de activiteiten-, de event- en de procesbeschrijving. Zo komen we tot het 
kwalitatieve of conceptueel model, dat de basis vormt voor het kwantitatieve 
model. 


2.2 Systemen 


Een voor dit moment geschikte definitie van systeem is de volgende (In ’t Veld 


1984): 


Een systeem is een, afhankelijk van het door de onderzoeker gestelde doel, 
binnen de totale werkelijkheid te onderscheiden verzameling elementen. 
Deze elementen hebben onderlinge relaties en (eventueel) relaties met 
andere elementen uit de totale werkelijkheid. 


In plaats van de term element wordt bij simulatietoepassingen vaak de term 
component gebruikt. In figuur 2.1 zijn een aantal voorbeelden van een systeem 
weergegeven. Daarvan wordt het tankstation in voorbeeld 2.1 nader toegelicht. 
Dit voorbeeld zal in dit boek stap voor stap worden uitgewerkt (een aantal van 
de hierbij voorkomende begrippen zijn ontleend aan Kerbosch et al. 1973). 
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Systeem Componenten Relaties 

tankstation auto’s, pompen, wachtrij de auto’s staan in 
een wachtrij, de auto’s 
tanken aan een pomp 


supermarkt klanten, kassa’s, de klanten worden door 
kassieres, wachtrijen de kassiéres aan de 
| kassa’s geholpen 


fabriek orders, machines, de werknemers voeren 
werknemers, wachtrijen met behulp van de ma- 
chines de orders uit. 


Figuur 2.1: Een drietal voorbeelden van een systeem 


situatieschets: 


N 


g ae 
ani van: in, 


systeemgrens 


Aan een verkeersweg bevindt zich een tankstation met een pomp. Vóór 
de pomp is een beperkte wachtruimte voor maximaal p auto’s (zie situatie- 
schets). De eigenaar heeft de indruk dat er nogal wat klanten doorrijden 
omdat er geen plaats meer is op het emplacement en overweegt de bestaande 
wachtruimte met een plaats uit te breiden. Daarom wil hij inzicht hebben 
in het percentage doorrijders en in de gemiddelde wachttijd in de huidige 
situatie (p = 3) en voor de overwogen nieuwe situatie (p = 4). 


De auto’s in de rij worden bediend op grond van “first in, first out’, afge- 
kort FIFO. 


Voorbeeld 2.1: Een tankstation met een beperkte wachtruimte 
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2.2.1 Het karakteriseren van een systeem 
Voor het bestuderen van een systeem bestaan er twee benaderingsmethoden: 


e vanuit het geheel (top-down), 
e vanuit de elementen (bottum-up). 


Bij de eerste methode, die kenmerkend is voor de zogenaamde ‘systeembenade- 
ring’, wordt een systeem in eerste instantie opgevat als een ‘black-box’ met de 
nadruk op de interactie met de omgeving. Bij de tweede methode gaat men uit 
van de componenten van een systeem en de relaties tussen deze componenten 
(zie definitie ‘systeem’). Bij simulatietoepassingen zijn beide benaderingsme- 
thoden van belang. 


2.2.2 De systeembenadering (top-down) 


In figuur 2.2 is een systeem in relatie tot zijn omgeving getekend. Uit de doel- 
stelling van het onderzoek dient afgeleid te worden welk deel van de werke- 
lijkheid men als systeem wenst te beschouwen; dit is het vaststellen van de 
zogenaamde systeemgrens. De van belang zijnde variabelen of grootheden die 
eveneens uit de doelstelling van het onderzoek volgen, kunnen in drie groepen 
worden ingedeeld. 


stuurvariabelen 


aan 


omgevings- systeem uitgangsvariabelen 


variabelen 


Figuur 2.2: Een systeem in relatie tot zijn omgeving 


De uitgangsvariabelen, ook wel afhankelijke of endogene variabelen ge- 
noemd, hebben betrekking op de functie van het systeem in zijn omgeving. 
Het vervullen van die functie in de omgeving is het doel van het systeem. 


De ingangsvariabelen, ook wel onafhankelijke of exogene variabelen ge- 
noemd, kunnen worden onderscheiden in stuurvariabelen of beslissingsvaria- 
belen welke gebruikt worden om het systeem bewust te beïnvloeden, en in 
omgevingsvariabelen die als een gegeven externe invloed op het systeem aan- 
wezig zijn. 


Met betrekking tot voorbeeld 2.1 omsluit de systeemgrens de pomp, de 
eventueel aanwezige auto’s (zowel de bediende als de in de wachtrij staande 
auto’s) en de uitvoeg- en invoegstrook. Daardoor zal een aankomende auto 
die een volle wachtrij ziet en doorrijdt voor een korte tijd deel uitmaken van 
het systeem. De aankomsttijden en de bedieningstijden van de aankomende 


e 
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auto’s, vormen hier de omgevingsvariabelen. De stuurvariabele bestaat uit de 
grootte p van de wachtruimte. De uitgangsvariabelen bestaan uit, enerzijds de 
vertrekkende auto’s en anderzijds uit de gewenste informatie: ‘het percentage 
doorrijders’ en de ‘gemiddelde wachttijd’. 


Om een duidelijk onderscheid aan te brengen tussen het reële systeem met 
zijn output in de vorm van vertrekkende auto’s en de aan het reële systeem 
te ontlenen gewenste informatie (“gemiddelde wachttijd’ etc.) delen we het 
systeem op in twee delen. Zie figuur 2.3. De waarnemer moet er voor zorgen dat 
de gewenste informatie (‘gemiddelde wachttijd’ etc.) wordt verkregen. Hiertoe 
verricht hij interne registraties. 


waarnemer ‘gemiddelde wachttijd’ enz. 


stuurvariabelen : ‘ 
registraties door waarnemer 


reéle systeem vertrekkende auto's 


aankomende auto's 


Figuur 2.3: Het tankstation voorgesteld als een 
reéel systeem met waarnemer 


Via de bottom-up aanpak worden hierna de componenten en de structuur 
van het reële systeem bepaald. 


2.2.3 De componenten en hun eigenschappen (bottom- 
up) 


De componenten (ook wel elementen, objecten of entiteiten genoemd) zijn de 
kleinste delen van het reële systeem die de onderzoeker wenst te beschouwen. 
De componenten van een systeem kan men op grond van gelijksoortig gedrag 
indelen in componentklassen. Dit zal samenhangen met de eigenschappen of 
attributen die men aan de component wil onderscheiden. 

Bij het tankstation gedragen alle auto’s zich op soortgelijke wijze. De auto’s 
vormen een componentklasse. Hetzelfde geldt voor de pomp(en). Bij dit voor- 
beeld zou naast een klasse van personenauto’s bijvoorbeeld nog een klasse van 
vrachtauto’s binnen het tankstationsysteem kunnen worden onderscheiden, in- 
dien het gedrag van vrachtauto’s binnen het tankstation essentieel anders zou 
zijn dan het gedrag van personenauto’s. 
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Een component wordt nader gespecificeerd door de waarden van zijn attri- 
buten. Bij de auto’s zijn dit het moment van aankomst en de bedieningstijd, 
voor de wachtrij de lengte van de wachtrij, en voor de pomp het al dan niet 
bezet zijn hiervan. 

Componenten die tot een klasse behoren, verschillen alleen ten aanzien van 
hun attribuutwaarden. 


Men onderscheidt tijdelijke en permanente componenten. Een component 
heet tijdelijk als deze niet gedurende het gehele tijdsinterval waarin het reele 
systeem wordt beschouwd daarvan deel uitmaakt. In voorbeeld 2.1 zijn de 
auto’s tijdelijke componenten en de pomp en de wachtrij permanente compo- 
nenten. Soms kan men permanente componentklassen nog verder opsplitsen in 
beweeglijke en vaste componentklassen. Bijvoorbeeld binnen een fabriek kun- 
nen vorkheftrucks beweeglijke en machines vaste componentklassen zijn. 


2.2.4 Relaties tussen componenten; toestand van een 
systeem, event en proces 


De verzameling relaties tussen de componenten van een systeem noemt men 
de structuur van het systeem. 


(De in de definitie van systeem genoemde relaties met componenten van 
buiten het systeem, worden gevat onder de reeds genoemde ingangs- en uit- 
gangsvariabelen. ) 

De elementen kunnen elkaar zo beinvloeden. Dit betekent dat een verande- 
ring van de waarde van een attribuut van een element een verandering in 
waarde van attributen van andere elementen tot gevolg kan hebben en even- 
tueel omgekeerd. Bijvoorbeeld het niet meer bezet zijn van de pomp kan tot ge- 
volg hebben dat de lengte van de wachtrij wordt verlaagd met één. De toestand 
van het systeem zal zich wijzigen. 


De toestand van een systeem op een bepaald tijdstip wordt volledig be- 
schreven door de waarden van de attributen van de componenten van het 
systeem op dat moment. 


De attributen, waarvan de waarden in de loop der tijd kunnen veranderen, 
worden toestandsvariabelen genoemd. In het voorbeeld 2.1 zijn het al of niet 
bezet zijn van de benzinepomp en het aantal auto’s in de wachtrij de toestands- 
variabelen. De toestand van een systeem op een gegeven ogenblik is een gevolg 
van voorafgaande gebeurtenissen of events. 


Het moment waarop de toestand van een systeem verandert, noemt men 
een eventtijdstip. 


Een event vormt de aanleiding tot een of meer op hetzelfde eventtijdstip 
plaatsvindende activiteiten die de toestand van het systeem doen verande- 
ren. 


12 2 - Systeembenadering en beschrijvingswijzen van discrete modellen 


De events kan men indelen in klassen op grond van het gelijksoortig zijn van 
de erbij behorende activiteiten en toestandsveranderingen die daarbij plaats 
kunnen vinden. Bij het tankstation zijn de aankomsten van de auto’s events 
van dezelfde klasse, immers al deze events kunnen aanleiding geven tot een 
soortgelijke verandering van het systeem, namelijk verlenging van de wachtrij 
c.q. bezetting van de pomp. Het beëindigen van het tanken van een auto is 
een event van een andere klasse, immers dit event geeft aanleiding tot het 
vrijkomen van de pomp c.q. de bezetting van de pomp door de eerste auto uit 
de wachtrij. 


De toestand van het systeem wordt steeds veranderd door activiteiten. De 
feitelijke uitvoering van de activiteiten vindt plaats door de componenten. 


De door een bepaalde component in de loop der tijd uit te voeren activitei- 
ten wordt een proces genoemd. 


In voorbeeld 2.1 vormen de volgende ‘activiteiten’ een voorbeeld van een 
proces van een auto: aankomst auto op tijdstip t1, wachten op het emplacement 
(wachtrij) gedurende t2, het tanken gedurende 3 tijdseenheden en vervolgens 
het vertrek. 


2.2.5 Soorten systemen 


In het algemeen kunnen de volgende soorten systemen onderscheiden worden: 


a. Statische en dynamische systemen. 
Bij dynamische systemen is minstens één vb E ER een functie 
van de tijd. Bij statische systemen is dit niet het geval. 


b. Deterministische en stochastische systemen. 
Bij stochastische systemen is er tenminste één stochastische variabele, die 
het gedrag van het systeem beïnvloedt. Bij deterministische systemen zijn 
er geen stochastische variabelen. 


c. Discrete en continue systemen. 
Een systeem is een discreet systeem wanneer alle toestandsvariabelen 
van het systeem discrete functies van de tijd zijn. De toestand van zo’n 
systeem verandert slechts op een bepaald aantal momenten. Tussen twee 
opeenvolgende eventtijdstippen verandert de toestand van het systeem 
niet. De veranderingen zelf verlopen tijdloos. De in figuur 2.1 genoemde 
voorbeelden zijn voorbeelden van discrete systemen. De componenten 
van een discreet systeem doorlopen scherp gescheiden fasen. Wanneer een 
component overgaat in een volgende fase, verandert de toestand van het 
systeem. Dit zijn ook de enige momenten waarop de toestand verandert. 
Het systeem gaat als het ware schoksgewijs van de ene toestand over in 
de volgende toestand. Bij een tankstation bijvoorbeeld worden de toe- 
standsveranderingen veroorzaakt door aankomst respektievelijk vertrek 
van een auto. De auto’s doorlopen de scherp gescheiden fasen ‘wachtend’ 
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en ‘in bediening’, de pomp doorloopt de fasen ‘bezig’ en ‘niet bezig’ (zie 
ook figuur 2.5). 


Men spreekt van een continu systeem wanneer de toestand van het sys- 
teem in de tijd continu verandert. Er is dan tenminste één toestands- 
variabele die een continue functie van de tijd is. Thermische processen, 
de groei van planten en analoge elektrische schakelingen zijn voorbeel- 
den van continue systemen. Soms is het door een geschikte keuze van het 
model toch mogelijk een continu systeem discreet te behandelen, bijvoor- 
beeld een continu productieproces kan soms worden voorgesteld als een 
regelmatige serie kleine ‘batches’. 


Wij zullen ons in het vervolg slechts bezighouden met dynamische, stochasti- 
sche, discrete systemen, kortweg aan te duiden met ‘systeem’. 


2.3 Modellen 


We zullen hier onder een model verstaan: 


Een model is een vereenvoudigde afbeelding van een reëel systeem waarbij 
alleen die componenten en relaties worden beschouwd die van belang zijn 
binnen het kader van de gegeven probleemstelling. 


Een model is dus een vereenvoudigde afbeelding van de realiteit, maar komt 
qua structuur wel overeen met die realiteit. Bij deze afbeelding kunnen afbeeld- 
fouten worden gemaakt. 


Voorbeeld 2.2: Het model van het tankstation. 


Uitgaande van de in voorbeeld 2.1 gegeven omschrijving van het tankstation 
zijn de volgende componentklassen te onderscheiden: 


Vaste componentklassen: 


e pomp, 
e wachtrij. 


Tijdelijke componentklasse: 
e auto. 


Om tot de structuur van het model te komen zullen we tussen de compo- 
nentklassen de relaties moeten aangeven. Dit kan door het proces, dat door- 
lopen wordt door de tijdelijke (beweeglijke) componenten, te beschouwen. We 
nemen hierbij aan dat een aankomende auto ook bij een leeg systeem via de 
wachtrij plaats neemt bij de pomp. 


De structuur van het model is in figuur 2.4 weergegeven. 
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systeemgrens 


Figuur 2.4: Een grafische weergave van het conceptueel 
model van het tankstation 


De betekenis van de gebruikte symbolen is: 


rechthoek : permanente component (behalve wachtrij) 

driehoek : wachtrij 

ruit : keuze 

pijl : bewegingsrichting van tijdelijke (beweeglijke) component. 


In figuur 2.4 is aangegeven dat de tijdelijke component betrokken kan zijn 
bij de activiteiten: aankomst, doorrijden, inrij, wachten, uitrij, tanken en ver- 
trek. De wachtrij is betrokken bij inrij, wachten, uitrij en de pomp bij uitrij, 
tanken en vertrek. 

Voor een aantal activiteiten kan worden aangegeven dat ze op een zeker 
tijdstip plaatsvinden (aankomst, doorrijden, inrij, uitrij en vertrek), andere 
activiteiten gaan gepaard met een zekere tijdsduur (wachten en tanken). 

Aangezien bij discrete modellen alle toestandsveranderingen momentaan 
plaatsvinden zullen we alle activiteiten die men in het reële systeem wil onder- 
scheiden moeten beschrijven middels activiteiten die tijdloos zijn. Dit wil hier 
zeggen dat het wachten wordt beschreven als een interval dat start met ‘inrij’ 
en waarvan de beëindiging wordt aangeduid met ‘uitrij’. Evenzo geldt voor het 
tanken dat het start met ‘uitrij’ en dat de beëindiging wordt aangeduid met 
‘vertrek’. 


De samenhang tussen de hiervoor genoemde activiteiten in de tijd is aan- 
gegeven in figuur 2.5. 

In figuur 2.5 is tevens aangeduid welke modelaannames we zullen gaan 
maken om binnen het kader van de doelstellingen tot een eenvoudig doch re- 
alistisch model te komen. Deze aannames (afbeeldfouten) zijn: 


e De tijd vanaf het aankomstmoment in het systeem tot het tijdstip dat 
de auto doorrijdt (bij volle wachtrij) of tot het tijdstip dat de auto in de 
wachtrij heeft plaatsgenomen wordt verwaarloosd (het eventuele wachten 


begint bij A0), 
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(wachten) (tanken) 
WWWWWWWWWWWWWWW TTTTTTTTT 
--|---|---|------------- | ---|------- | --|-------- realiteit 


AO Ai A2 (A3) A41 A42 A51 A52 tijd | 
| | | |afbeeldfouten 
| | | | 
WWWWWWWWWWWWWWWWWWWWWWWTTTTTTTTTTTT Y 
--- | --------------------- | ----------- nme o 
AO (A3) A4 A5 tijd 
Ai 
A2 


AO: AANKOMST in systeem 

A1: DOORRIJDEN 

A2: INRIJ 

(A3: SCHUIFDOOR in wachtrij t.g.v. het vertrek van een voorganger) 
A41: auto uit rij 
A42: start tanken 

A4: UITRIJ (= A41 + A42) 
A51: tanken klaar 
A52: vertrek 

A5: VERTREK (= A51 + A52) 


Figuur 2.5: Onderkende activiteiten in realiteit en model 


e De tijd nodig om de wachtrij te verlaten en naar de pomp te rijden wordt 
in de bedieningstijd verdisconteerd (de periode A41-A42 wordt ook als 
tanktijd opgevat), 

e Het vertrek van de auto valt samen met het moment dat de bediening 
klaar is (A52 valt samen met A51). 


Modelaannames met betrekking tot de keuze van verdelingen voor tussen- 
aankomsttijden en bedieningstijden van de auto’s worden in hoofdstuk 4 (sta- 
tistische aspecten) behandeld. Deze afbeeldfouten hebben namelijk betrekking 
op het kwantitatieve model. 


Wanneer men tot iedere prijs het maken van afbeeldfouten wenst te voor- 
komen, kan het model zeer gecompliceerd worden. Men zal steeds schipperen 
tussen aan de ene kant ‘de mate waarin het model lijkt op de werkelijkheid’ 
en aan de andere kant de doorzichtigheid ervan. Men dient daarbij na te gaan 
welke afbeeldfouten worden gemaakt en in hoeverre deze afbeeldfouten de re- 
sultaten van het onderzoek beïnvloeden. 


We gaan nu het model van het tankstation detailleren door de component- 


klassen nader te specificeren: 


De toestandsvariabelen zijn in dit voorbeeld de attributen van de vaste com- 


ponentklassen: RIJLENGTE en POMPVRIJ. 
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Om het gedrag van het systeem als functie van de tijd te kunnen beschrijven 
wordt een variabele TIME ingevoerd, die de systeemtijd weergeeft. 

Voor het verkrijgen van de gewenste output (zie figuur 2.3) worden de 
volgende hulpvariabelen gedefinieerd: 


NAANKOMST : aantal aangekomen auto’s tot nu toe 
NBEDIEND : aantal bediende auto’s tot nu toe 
NDOORRIJDEN : aantal doorgereden auto’s tot nu toe 
WACHTTIJDi : wachttijd AUTOi 


De in figuur 2.5 gedefinieerde activiteitsklassen geven aanleiding tot de 
volgende veranderingen van de waarden van variabelen. (N.B. de toestandsva- 
riabelen zijn cursief gedrukt): 


activiteitsklassen verandering van variabelen 
AANKOMST : auto komt systeem NAANKOMST := NAANKOMST + 1 
binnen 
DOORRIJDEN: auto rijdt door © NDOORRIJDEN := NDOORRIJDEN + 1 
INRIJ : auto in rij RIJLENGTE := RIJLENGTE + 1 
SCHUIFDOOR: auto schuift door in rij 


UITRIJ : auto uit rij + start RIJLENGTE  := RIJLENGTE — 1 
tanken POMPVRIJ [= FALSE 
WACHTTIJDi := TIME-AANKOMSTTIJDi 
VERTREK : tanken klaar + vertrek POMPVRIJ = TRUE 
NBEDIEND ‘= NBEDIEND + 1 


In het bovenstaande staat AANKOMSTTIJDi voor de AANKOMSTTIJD van 
de i-de auto. Voor het kunnen uitvoeren van een daadwerkelijke simulatie 
moeten de activiteiten, die op hun beurt de toestandsveranderingen veroor- 
zaken, nog in de tijd worden geordend. 

De hiervoor behandelde activiteitsklassen kunnen daarbij op verschillende 
manieren worden gegroepeerd. Afhankelijk van de wijze van groeperen ontstaan 
de volgende drie beschrijvingswijzen: 


e activiteitenbeschrijving (afzonderlijke beschrijving van elke activiteit met 
bijbehorende voorwaarden) 


e eventbeschrijving (groepering activiteiten rondom tijdstip van op- 
treden event) 
e procesbeschrijving (groepering activiteiten rondom componenten) 


Deze beschrijvingswijzen zullen in de volgende paragrafen behandeld worden. 
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2.4 De activiteitenbeschrijving 


Bij het gebruik van een activiteitenbeschrijving wordt het systeem beschre- 
ven door een beschrijving te geven van alle soorten activiteiten (handelingen, 
acties) die in het systeem voor kunnen komen. Voor iedere activiteitsklasse 
dienen de voorwaarden te worden gegeven waaraan moet zijn voldaan om die 
activiteit uit te kunnen voeren. Deze voorwaarden kunnen afhankelijk zijn van 
de systeemtijd. 

Bij het tankstationprobleem kunnen de volgende voorwaarden aan de hier- 
voor gedefinieerde activiteitsklassen worden toegevoegd: 


IF TIME=AANKOMSTTIJD THEN AANKOMST 

IF TIME=AANKOMSTTIJD en RIJLENGTE = p THEN DOORRIJDEN 

IF TIME=AANKOMSTTIJD en RIJLENGTE < p THEN INRIJ 

IF RIJLENGTE > 0 en POMPVRIJ=TRUE THEN UITRIJ + SCHUIFDOOR 
IF ‘TIME=eindtijd actuele bediening THEN VERTREK 


Met betrekking tot het bovenstaande kunnen we opmerken dat de tijdvoor- 
waarde van de eerste drie activiteitsklassen identiek is. Deze activiteitsklas- 
sen kunnen daarom gezamenlijk worden beschreven. Van de activiteitsklassen 
UITRIJ en SCHUIFDOOR geldt dat de activiteit SCHUIFDOOR steeds in 
combinatie met UITRIJ voorkomt en deze kunnen daarom ook als een geheel 
worden beschreven. Zodoende kunnen we ons hier in wezen beperken tot de 
volgende (samengestelde) activiteitsklassen: 


1. Plaats een auto in de wachtrij. 

Hier is de voorwaarde dat door de systeemtijd wordt aangegeven dat het 
aankomstmoment van een auto bereikt is. 

De auto wordt aan de wachtrij toegevoegd, tenzij de wachtrij daardoor 
meer dan p auto’s zou gaan bevatten. Door de aankomst van de auto 
start er een pauzeduur tussen twee aankomsten. 

(De duur van die pauze wordt bijvoorbeeld bepaald door middel van een 
trekking uit de verdeling van tussenaankomsttijden. Hierdoor wordt een 
volgend eventtijdstip verkregen waarop er weer een auto zal arriveren). 


2. Plaats een auto bij de pomp. 
De voorwaarden zijn: 


e de pomp is vrij, 
e er is een auto in de wachtrij. 


Zodra een dergelijke situatie optreedt, zal de voorste auto in de wachtrij 
bij de pomp worden geplaatst, waardoor de pomp wordt bezet. Het bedie- 
ningsproces gaat dan van start. (De duur van die bediening wordt bijvoor- 
beeld bepaald door middel van een trekking uit de verdeling van bedie- 
ningstijden. Hierdoor wordt een volgend eventtijdstip verkregen waarop 
een bediening klaar komt.) 

Indien er nog auto’s in de wachtrij zijn overgebleven schuiven deze een 
plaats in de wachtrij door. 
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3. Verwijder een auto uit het systeem. 
De voorwaarde is nu dat de systeemtijd het moment aangeeft, dat een 
pompbediening is klaargekomen. De auto bij de pomp zal dan het systeem 
verlaten, waardoor de pomp weer vrij komt. 


Bij simulatie van het hier beschreven model worden de voorwaarden van alle ac- 
tiviteiten achtereenvolgens gecontroleerd (zie figuur 2.6). Wordt aan alle voor- 
waarden voor het starten van een activiteit voldaan, dan wordt die activiteit 
uitgevoerd. 


voor- te i 
waarden activiteit 


act. j klasse 1 


voor- 
waarden 
act. n 


activiteit 
klasse n 


Figuur 2.6: Stroomschema activiteitenbeschrijving (rangschikking activiteiten 


in volgorde van optreden) 
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Kan geen activiteit meer worden uitgevoerd, dan zal de systeemtijd worden 
verhoogd tot het eerstvolgende eventtijdstip. Hiervoor zorgt de ’klok’ in figuur 
2.6. (De werking van de klok wordt nader toegelicht in 2.5). 

Omdat bij elk eventtijdstip steeds alle voorwaarden worden gecontroleerd 
is de methode niet bijzonder efficiënt. Het voordeel is echter, dat in een pro- 
gramma-onderdeel waar de beschrijving van een activiteit aan de orde komt 
ook alle bijzonderheden van die activiteit zijn te vinden. 


2.5 De eventbeschrijving 


Onder een eventbeschrijving verstaan we: 


De beschrijving van alle (activiteiten en bijbehorende) toestandsverande- 
ringen die op een eventtijdstip kunnen plaatsvinden. 


Bij een eventbeschrijving gaat het uiteindelijk om de er door veroorzaakte 
toestandsveranderingen. Om de relatie met de andere beschrijvingswijzen dui- 
delijk aan te kunnen geven zullen we als tussenstap de activiteitsklassen be- 
schouwen. Door figuur 2.5 uit te breiden voor meerdere auto’s zien we dat 
activiteit A4 van auto n samen kan vallen met A5 van auto n-1 (zie figuur 
2.7). 


WWWWWWWWWWWTTTTT 
auto nri =|e==samane | manne | penn nnn nnn nnn nnn nnn nnn == == == 
AO A4 A5 tijd 
A2 | 
| 
WWWWWWWWWWITTT 
REN emme J shen mentite ‘Baete ‘ssn than trant oodaanbetemehttatert eischen go ag 
AO A4 AS tijd 
A2 | 
| 
WWWWWWWWWWWTTTTT 
auto nti  ---=etmben prose ene J sem | pene yma min oe nanaman aniio en en en epee 
AO A4 AS tijd 
A2 


Figuur 2.7: De activiteiten van opeenvolgende tijdelijke componenten 


Indien bij aankomst van auto n het systeem leeg is zal voor auto n A4 
samenvallen met AQ. We zien dus dat in het geval van het tankstation de 
activiteiten A0, Al, A2 en A4 op hetzelfde eventtijdstip kunnen plaatsvinden. 
Het bij AO behorende event duiden we aan met ‘Aankomst’ omdat activiteit 
A0 steeds de oorzaak is van het eventueel optreden van de overige activiteiten. 
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Evenzo is de oorzaak van het activiteitencluster A5, A4 de activiteit A5. Dit 
event wordt gemakshalve aangeduid met ‘Vertrek’. 


Voor de events Aankomst (= A) en Vertek (= V) van een auto luiden de 
eventbeschrijvingen dan: 


A (Aankomst) : Indien de pomp vrij is wordt deze bezet: anders wordt de 
wachtrij één langer, tenzij de wachtrij daardoor langer wordt 
dan p auto’s, dan zal de auto doorrijden. 

V (Vertrek): De pomp komt vrij. Indien er nog auto’s in de wachtrij staan, 
dan gaat de voorste auto uit de wachtrij naar de pomp. De 
eventueel aanwezige overige auto’s schuiven een plaats op in 
de wachtrij. Indien er geen auto’s in de wachtrij staan, gebeurt 
er niets en is het wachten op een volgende aankomst. 


De eventbeschrijvingen kunnen we als volgt omschrijven. (De verandering van 
de waarden van toestandsvariabelen staat tussen haakjes toegevoegd): 


A : AANKOMST; 
IF RIJLENGTE = = p THEN DOORRIJDEN ELSE INRIJ (RISLENGTE:=RIJLENGTE+1) 


IF POMPVRIJ=TRUE THEN UITRIJ (RIJLENGTE:=RIJLENGTE-1) 
POMPVRIJ:=FALSE) 
V : VERTREK (POMPVRIJ:=TRUE); 
IF RIJLENGTE > 0 THEN UITRIJ (RIJLENGTE:=RIJLENGTE-1 


POMPVRIJ:=FALSE) 
IF RIJLENGTE > 0 THEN SCIIUIFDOOR. 


Met de eventbeschrijvingen is de werking van het systeem nog niet volledig 
vastgelegd. Er is namelijk nog niet beschreven op welke tijdstippen de diverse 
events plaatsvinden. Wanneer we zouden beschikken over een lijst van alle 
eventnotities (d.w.z. het eventtijdstip en bijbehorende eventklasse) dan zou 
een beschrijving van het systeem volledig gemaakt kunnen worden met het 
volgende voorschrift: 


Werk in chronologische volgorde de lijst af en voer de in de eventbeschrij ving 
voorgeschreven activiteiten uit. 


Iet vooraf ontwerpen van een volledige lijst van eventnotities is omslachtig 
en vaak onmogelijk. 

Op ieder moment zijn we echter slechts iii esoerd in het eerstvolgende 
event (zie ook handsimulatie hoofdstuk 3). Het is daardoor mogelijk de lijst 
van eventnotities beperkt te houden. We moeten er alleen voor zorgen dat 
deze lijst altijd tenminste een eventnotitie (het eerstvolgende) bevat. We zullen 
hiertoe het volgende mechanisme hanteren, dat er voor zorgt dat de lijst van 
eerstkomende eventnotities niet groter dan noodzakelijk is. 


1. Klokmechanisme: Selecteer de eerstvolgende eventnotitie. Dit kan in ons 
geval zowel op een aankomst als een vertrek betrekking hebben. 
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event- 
beschrijving 
klasse 1. 


event- event- 
klasse > beschrijving 
n? klasse n 


start+initialisaties; 
WHILE not klaar DO 
BEGIN neem volgend event (klok); 
IF eventklasse=1 THEN eventbeschrijving klasse 1; 


IF eventklasse=n THEN eventbeschrijving klasse n; 
END 


Figuur 2.8: Stroomschema en pseudocode eventbeschrijving 
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2. Werk voor het onder punt 1. geselecteerde event alle activiteiten af. Voeg 
indien nodig een nieuwe eventnotitie aan de lijst toe. Verwijder de onder 
punt 1 genoemde eventnotitie uit de lijst. 

3. Ga naar 1. 


Het bijbehorende stroomschema is weergegeven in figuur 2.8. Tevens is in deze 
figuur de eventbeschrijving in pseudocode opgenomen. 


Het bepalen van toekomstige eventtijdstippen en het vormen van de des- 
betreffende notities dient in de eventbeschrijving te worden opgenomen. In het 
geval van het tankstation: 


e Bij aankomst : Bepaal het volgende aankomsttijdstip bijvoorbeeld met be- 
hulp van een trekking uit een verdeling van de tussenaan- 
komsttijden. 

e Bij vertrek : Indien er nog een wachtende auto aanwezig is bepaal dan 


het vertrektijdstip van deze auto bijvoorbeeld door een 
trekking uit een verdeling van de bedieningstijden. 


Soms blijken eventbeschrijvingen een hoge mate van overeenkomst te verto- 
nen. Bijvoorbeeld stel dat er eventbeschrijvingen zijn van aankomsten van een 
order van soort 1 en van soort 2 die slechts in geringe mate verschillen. Men 
kan dan de aankomsten van de twee ordersoorten onderbrengen in één event- 
klasse: de aankomst van een order. Om toch een onderscheid tussen de twee 
typen orders te kunnen maken moet deze eventbeschrij ving wel een parameter 
ordersoort hebben. Ditzelfde kan mogelijk ook voor de eventbeschrijving van 
het beschikbaar komen van machines. Hierdoor kan men soms zelfs voor een 
vrij ingewikkeld systeem volstaan met een gering aantal eventtypen. 


Als we de hier gegeven eventbeschrijving vergelijken met de activiteitenbe- 
schrijving dan zien we dat de eventbeschrijving uit twee klassen en de activi- 
teitenbeschrijving uit drie klassen bestaat. Hoe kan dat? 

Dit komt doordat de afzonderlijk omschreven activiteit ‘plaats een auto bij 
de pomp’ (= auto uit rij + schuifdoor + start tanken) bij een event beschouwing 
altijd samen valt met een ‘aankomst’ van een nieuwe auto of het ‘vertrek’ van 
een vorige auto (zie ook figuur 2.7). 


2.6 De procesbeschrijving 


Een procesbeschrijving van een componentklasse is de beschrijving van 
de activiteiten die een component van die klasse kan uitvoeren en van de 
daarbij behorende interacties met de overige componentklassen. 


In figuur 2.9 zijn verschillende procesbeschrijvingen met hun onderlinge 
interacties (aangeduid met stippellijnen) globaal weergegeven. Het klokmecha- 
nisme is hier ‘verdeeld’ over de verschillende procesbeschrijvingen. 
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initialisaties 


proces- proces- proces- 
beschrijving beschrijving beschrijving 
n 


Figuur 2.9: Het globale stroomschema volgens de procesbeschrijving. De 
stippellijnen symboliseren de interacties tussen de procesbeschrijvingen. 


Het totale aantal activiteiten dat door alle componenten tesamen (het gehele 
systeem) wordt uitgevoerd veroorzaakt de toestandsveranderingen. Deze toe- 
standsveranderingen mogen uiteraard niet afhangen van de gehanteerde be- 
schrijvingswijze. Dit wil hier zeggen dat elk van de onderkende activiteiten _ 
eenduidig moet worden toegewezen aan een component die voor de uitvoe- 
ring ervan zorgdraagt. Aan welke componentklasse een activiteitsklasse wordt 
toegewezen is hierbij in principe niet van belang. Echter om een modulaire 
structuur te bevorderen (vooral van belang bij implementatie) wordt een acti- 
viteitsklasse bij voorkeur toegewezen aan die componentklasse, die als attribu- 
ten toestandsvariabelen bevat die door de activiteitsklasse gewijzigd worden. 

Met betrekking tot voorbeeld 2.1 kunnen de onderscheiden activiteitsklas- 
sen worden toegewezen aan de componentklassen zoals bijvoorbeeld weergege- 
ven in figuur 2.10 
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Activiteitsklassen Componentenklassen Verandering toestands- 
variabele 
auto wachtrij pomp 


AANKOMST 


X 
DOORRIJDEN X 
INRIJ X 
UITRIJ POMPVRIJ 
SCHUIFDOOR RIJLENGTE 
VERTREK POMPVRIJ 


RIJLENGTE 


Figuur 2.10: Activiteitsklassen toegewezen aan componentklassen 


In deze figuur zijn tevens de toestandsvariabelen genoemd die door de ge- 
noemde activiteiten worden gewijzigd. Merk op dat deze toestandsvariabelen 
bij andere componentklassen (kunnen) behoren dan de verandering veroor- 
zakende componentklasse. (Voorbeeld: INRIJ behorende bij auto wijzigt de 
toestandsvariabele RIJLENGTE van de wachtrij). Bovendien kan het voorko- 
men dat een componentklasse in het geheel geen activiteitklasse(n) toebedeeld 
gekregen heeft. Een dergelijke componentklasse blijft echter van belang als er 
toestandsvariabelen aan gekoppeld zijn. 

We zullen nu het globale schema van figuur 2.9 gaan detailleren. De daar 
aangeduide procesbeschrijvingen zijn voor voorbeeld 2.1, uitgaande van figuur 
2.10, uitgewerkt tot figuur 2.11. Deze figuur is daarbij als volgt tot stand 
gekomen (voor de betekenis van de symbolen zie figuur 2.12): 


a. ‘Teken per componentklasse de toegewezen activiteiten in chronologische 
volgorde van boven naar beneden, 

b. Indien voor het optreden van een activiteit aan één of meer logische 
voorwaarde(n) voldaan moet worden, geef deze dan direct boven deze 
activiteit aan met behulp van een ruitsymbool, 

c. Indien voor het optreden van een activiteit gewacht moet worden op 
het optreden van een activiteit die door een andere componentklasse 
wordt uitgevoerd (interactie), geef dit dan aan met een wachtsymbool 
(driehoekje), 

d. Indien binnen een componentklasse voor het optreden van een activiteit 
gewacht moet worden tot er een zeker tijdstip binnen het systeem bereikt 
is (systeemtijd), geef dit dan aan d.m.v. een rondje (van een klok) boven 
deze activiteit, 

e. Geef interacties tussen de componentklassen weer met stippellijnen, die 
starten in de activiteit die deze interactie veroorzaakt en eindigt in een 
wachtsymbool. Opgemerkt dient te worden dat er ook interacties voor 
kunnen komen tussen activiteiten van dezelfde componentklasse. Het be- 
treft dan interacties tussen meerdere componenten van dezelfde klasse. 
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procesbeschrijving 
klasse auto 


wacht 
tot TIME = 
AANKOMST- 

FIJO 


AANKOMST 


wacht tot 
TIME=AANKOMSTTIJD; 
AANKOMST ; 

IF RIJLENGTE<p 
THEN INRIJ 

+ activeer pomp 
(indien onbezet) 
ELSE DOORRIJDEN; 


procesbeschrijving 
klasse pomp 


UITRIJ 


ele bedie- 
ningstijd 


VERTREK 


WHILE TRUE 

DO IF NOTCrijlengte>0) 
THEN 
wacht op INRIJ; 
UITRIJ 
+ activeer wachtrij; 
wacht tot 
TIME=e inde actuele 
bedieningst ijd; 
VERTREK; 


procesbeschrijving 
klasse wachtrij 


SCHUIFDOOR 


WHILE TRUE 

DO wacht op 
UITRIJ; 
SCHUIFDOOR; 

OD; 


Figuur 2.11: De procesbeschrijvingen met bijbehorende pseudocode 
programma’s voor het tankstation van voorbeeld 2.1 
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tijdloze activiteit 


tijdloze activiteit waarbij 
andere componenten gecreëerd 
en/of geactiveerd worden 


Logische voorwaarde 


wachten tot of gedurende 
(synchronisatie met systeemtijd) 


wachten op activering door een 
andere activiteit 
(synchronisatie met ander proces) 


begin of einde van een proces 


begin van een proces. Het proces 
wordt gecreëerd en geactiveerd 
door een component van de 
componentklasse waar de pijl 
vandaan komt. 


activeringspijl. Het proces waar 
de pijl naar wijst wordt 
geactiveerd. Als dit geactiveerde 
proces klaar is met zijn 
activiteiten die op dat moment 
uitgevoerd moeten worden wordt 
het proces waar de pijl vandaan 
kwam weer actief. 


Figuur 2.12: Betekenis symbolen procesbeschrijvingen 
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Met betrekking tot de procesbeschrijvingen in figuur 2.11 merken we verder 
nog het volgende op: 


a. Zoals reeds opgemerkt, wordt bij een procesbeschrijving elke activiteit 
precies één keer toegewezen aan een component die voor de uitvoering 
ervan zorgt draagt (en dus de toestandsverandering veroorzaakt). 
Daarom zien we deze activiteit niet voor een tweede keer terug bij de 
component die deze activiteit passief ondergaat. Bijvoorbeeld UITRIJ - 
wacht gedurende bediening - VERTREK wordt ondergaan door de auto 
maar is dus in diens procesbeschrijving niet zichtbaar. 

b. De procesbeschrijvingen zijn op componentklasse nivo. Dit wil zeggen dat 
bij simulatie van een volledig model elke component van een klasse een 
eigen procesbeschrijving toebedeeld krijgt die beschouwd kan worden als 
zijnde een copie van de bijbehorende componentklasse. De hier gegeven 
interactie-stippellijnen tussen de klassen representeren interacties tussen 
afzonderlijke componenten van die klassen. 

c. De procesbeschrijvingen zijn naast elkaar getekend om uit te drukken 
dat er componenten van verschillende componentklassen tegelijkertijd in 
het systeem aanwezig kunnen zijn. 

d. Zoals de meeste software worden ook discrete simulatiemodellen (nog) 
geïmplementeerd op sequentiële computersystemen waarvan de processor 
eigenlijk maar één ding tegelijk kan doen. Om de procesbeschrijvingen 
te implementeren wordt gebruik gemaakt van quasi-parallelliteit. 


aan 
voorwaarde voorwaarde 
voldaan? 


Figuur 2.13: In de rechter figuur vindt de de-activatie plaats totdat aan de 
voorwaarde is voldaan. 
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Dit betekent dat een proces alleen echt actief is als er echt een activiteit 
uit te voeren is. Dit zullen we proberen te verduidelijken aan de hand 
van figuur 2.13 (zie vorige pagina). 

Stel dat niet aan een bepaalde voorwaarde is voldaan. In het linkerschema 
zal voortdurend worden getest net zo lang tot aan de voorwaarde voldaan 
is (de processor van de computer is hier continu mee bezig; het pro- 
gramma blijft ‘hangen’). Willen we de sequentiële processor gedurende 
het ‘hangen’ voor een andere activiteit gebruiken dan kan dat volgens 
het rechterschema. Daar wordt één keer getest en als dan niet aan de 
voorwaarde is voldaan treedt een de-activering van het proces op. 

In deze laatste situatie kan gedurende de wachtperiode van het ene proces 
de processor voor de verwerking van een ander proces worden gebruikt 
dat dan actief wordt. Aan de wachtperiode van het eerste proces wordt 
een eind gemaakt door een ander proces dat er voor gezorgd heeft dat 
aan de voorwaarde voldaan is. De verwerking van het eerste proces kan 
nu worden voortgezet. 


. De componenten van de tijdelijke componentklassen doorlopen hun pro- 


cesbeschrijving een keer (procesbeschrijving ingesloten tussen ‘begin’ en 
‘klaar’); de componenten van de permanente componentklassen kunnen 
meerdere malen gedurende de hele simulatietijd doorlopen worden (wel 
‘begin’, geen ‘klaar’), 


. Merk op dat indien een component na het uitvoeren van een activiteit 


niet direct een volgende activiteit kan uitvoeren, deze component als niet- 
actief (gedeactiveerd) beschouwd mag worden. Een gedeactiveerde com- 
ponent kan op twee manieren weer actief worden: of doordat een bepaald 
tijdsinterval verstreken is (rondje) of doordat een andere component hem 
‘activeert’ (driehoek). 


. Merk op dat ook het verblijf van een tijdelijke component in de wachtrij 


niet zichtbaar is in de figuur. Dit komt doordat het ‘verblijf’ dat afge- 
bakend wordt door de tijdloze activiteiten INRIJ en UITRIJ, aan twee 
verschillende componentklassen zijn toegewezen. 

Merk tot slot op dat in de procesbeschrijving het aantal rondjes (= af- 
stemmingen in de tijd) gelijk is aan het aantal eventklassen bij de event- 
beschrijving (ga zelf na waarom). 


We zien dat de procesbeschrijving overeenkomst vertoont met een min of meer 
intuitieve beschrijving van voorbeeld 2.1. Het beschrijven van een systeem door 
middel van procesbeschrijvingen is een natuurlijke en voor de hand liggende 
wijze van beschrijven. 


We hebben tot nu toe ‘slechts’ het procesbeschrijvingen gedeelte van figuur 
2.9 gedetailleerd. Het resterende deel van deze figuur zullen we nu als volgt 
uitwerken (zie figuur 2.14): 


a. 


In figuur 2.9 en 2.11 is niet aangegeven wanneer de simulatie zal eindi- 
gen. In het algemeen wordt de duur van een simulatie bepaald door het 
verwerkt zijn van een bepaald aantal tijdelijke componenten of door het 
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verstrijken van een vooraf vastgestelde tijdsduur. Voor het beëindigen 
van de simulatie en voor het creëren van de verschillende componenten 
zullen we een nieuwe componentklasse ‘besturing’ invoeren. De hiervoor 
genoemde stopcriteria worden in deze componentklasse weergegeven door 
middel van de reeds geïntroduceerde symbolen ‘driehoek’ en ‘rondje’. 
De component ‘besturing’ in fig. 2.14 geeft precies aan in welke volgorde 
de componenten van de diverse klassen geactiveerd dienen te worden. 
Om een onderscheid aan te geven tussen de activiteiten van het reële 
systeem en de besturingsactiviteiten, zijn deze laatste met kleine letters 
aangeduid. 

b. In figuur 2.11 is er van uitgegaan dat elke individuele auto ‘achter de 
schermen’ wacht tot zijn aankomstmoment is aangebroken. Dat zou in- 
houden dat voor elke auto de procesbeschrijving gestart moet worden 
aan het begin van de simulatie. Het is echter realistischer de tijdelijke 
componenten te creëren en te starten op het moment van hun aankomst 
in het systeem. Om deze reden wordt de componentklasse ‘aankomst- 
generator’ ingevoerd, die de activiteit AANKOMST met bijbehorende 
tijdsvoorwaarde overneemt van de klasse auto (zie figuur 2.14). 

c. Tot dusver hebben we het reële systeem en zijn interactie met de omge- 
ving gemodelleerd. Er resteert nog (de registraties door) de waarnemer 
die de uiteindelijk gewenste informatie moet aanleveren (zie figuur 2.3). 
Om de procesbeschrijving zo goed mogelijk te laten aansluiten bij deze 
figuur 2.3 zullen we voor de waarnemer een aparte componentklasse in- 
voeren. Omdat de waarnemer geen deel uitmaakt van het reële systeem 
zullen binnen deze componentklasse geen activiteitsklassen voorkomen. 
De momenten waarop de waarnemer registraties moet verrichten opdat 
hij de gewenste informatie kan leveren, zullen we in de stroomschema’s 
aangeven met een *. In figuur 2.14 moeten registraties verricht worden 
van individuele wachttijden, het aantal bediende auto’s en het aantal 

_ doorgereden auto’s opdat de waarnemer de ‘gemiddelde wachttijd’ en 
het aantal doorgereden auto’s kan bepalen. 


2.7 Relatie tussen de drie beschrijvingswijzen 


In onderstaand overzicht is de relatie tussen de drie beschrij vingswijzen sche- 
matisch weergegeven: 


Act.klassen Ev.beschir. Procesbeschrijving Toestandsvariabele 


V generator auto rij pomp 

AANKOMST X X 

DOORRIJDEN 

INRIJ RIJLENGTE 

UITRIJ POMPVRIJ en 
RIJLENGTE 

SCHUIFDOOR 

VERTREK POMPVRIJ 
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creëer en 


creëer en creëer en creëer en pda 
activeer activeer activeer 

AANKOMST- 

WAARNEMER1 WACHTRIJ1 POMP 1 GENERATOR 


AANKOMST- 
GENERATOR 


wacht 
tot TIME = 
AANKOMST- 
TIJD 


CREEER EN 
ACTIVEER 
nieuwe auto 


SCHUIFDOOR 


ele bedie- 
ningstijd 


DOOR- 
RIJDEN ENRI 5 


KLAAR 


VERTREK 


{ )- 
a2 


| rapportage 


STOP 


Figuur 2.14: De volledige procesbeschrijving 


van het tankstation 
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2.8 Het kwantitatieve model 


Voor het uitvoeren van simulaties moeten de waarden van de attributen van 
alle componenten alsmede het aantal componenten van de verschillende per- 
manente componentklassen bekend zijn. Sommige attribuutwaarden kunnen 
direkt van een waarde worden voorzien. Andere attribuutwaarden zijn slechts 
in statistische zin bekend, zodat ten behoeve van de simulatie steeds trekkin- 
gen uit de bekende verdelingsfuncties moeten worden gedaan. Het kwalitatieve 
model gecombineerd met deze gegevens noemen we het kwantitatieve model. 


2.9 Opgaven 


l Beredeneer de juistheid in de volgorde van activeren door de component 
‘besturing’ in figuur 2.14 o 


2 *Over enige tijd zal voor het tankstation van voorbeeld 2.1 een spoor- 
wegovergang komen, welke elk half uur gedurende 5 minuten aan een 
stuk gesloten zal zijn. 

De eigenaresse van het tankstation vraagt zich af wat de invloed hiervan 
op de gemiddelde wachttijd bij de pomp en het percentage doorrijders 
zal zijn voor verschillende groottes van de wachtruimte voor de auto’s. 
Er moet een simulatie uitgevoerd worden met behulp van de eventbe- 
schrijving. 

Doorloop hiervoor de volgende stappen: 


a. Bepaal de relevante uitgangs-, omgevings-, stuur- en toestandsvari- 
abelen (= stap 2 van. werkwijze 7.2). 


b. Geef een grafische weergave van het conceptueel model (= stap 3 
van werkwijze 7.2). 


c. @ Bepaal per componentklasse de bijbehorende ‘activiteiten’. 
e Maak hiervan een doorsnede en som alle activiteitsklassen op. 
e Geef per activiteitsklasse de bijbehorende veranderingen van de 
toestandsvariabelen. 
(= stap 5 van werkwijze 7.2). 
d. Bepaal de eventklassen en geef per eventklasse een verbale event be- 
schrijving. 
e. Geef, in tabelvorm, voor elke activiteitsklasse aan in welke event- 
klasse deze voor kan komen. 
(= analogon van stap 6 van werkwijze 7.2). 
f. Teken het stroomschema van de eventbeschrijvingen. 
Ga hierbij uit van figuur 2.8 en detailleer daarbij de eventbeschrij- 
vingen eveneens in de vorm van een stroomschema. 
(= analogon van stap 7 van werkwijze 7.2). 
g. Geef aan welke metingen waar uitgevoerd moeten worden om aan 
de gewenste informatie te komen. o 
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3 In een kroeg staat een toog waaraan plaats is voor maximaal 5 perso- 


nen. Dorstigen arriveren in de kroeg (met negatief exponentieel verdeelde 
tussenaankomsttijden). 

Dorstigen die bij aankomst geen plaatsje vinden aan de toog lopen door 
naar de aanpalende kroeg. Als een dorstige bij aankomst ziet dat de tap- 
per niet bezig is met het helpen van een klant, dan waarschuwt de dor- 
stige de tapper dat hij/zij iets wil bestellen. De tapper tapt een drankje, 
geeft het aan de dorstige waarna deze elders in de kroeg plaatsneemt. Als 
er nog meer dorstigen aan de toog zitten neemt de tapper de volgende 
bestelling op, tapt etc. Als er geen dorstigen meer aan de toog zitten, 
gaat de tapper iets anders doen, totdat een nieuwe dorstige aan de toog 
plaatsneemt en te kennen geeft iets te willen bestellen. 

De bedieningstijd is homogeen verdeeld. De ‘rijdiscipline’ is FIFO. Men 
wil een simulatie uitvoeren om te bepalen: 


e hoeveel procent van de dorstigen doorloopt, 
e de tijd die men gemiddeld moet wachten op een drankje, 
e hoeveel procent langer dan een zekere tijd moet wachten. 


Maak een procesbeschrijving van deze kroeg aan de hand van de volgende 
stappen: 


a. De stappen a tot en met c van opgave 2. 


b. Wijs de activiteitsklasssen eenduidig toe aan de componentklassen 
(= stap 6 van werkwijze 7.2). 


c. Teken het stroomschema van de procesbeschrijvingen van de com- 
ponentklassen (= stap 7 van werkwijze 7.2). 


d. Geef in de stroomschema’s aan waar welke grootheden gemeten 
moeten worden door de ‘waarnemer’ om de gewenste informatie te 
kunnen leveren. o 


Beantwoord opnieuw de vragen a tot en met d van opgave 3 indien de dor- 
stigen zelf hun drankje tappen en na afloop hiervan de langst wachtende 
aan de toog waarschuwt dat deze aan de beurt is. Vergelijk de resultaten 
met de resultaten van opgave 3. o 


Beantwoord weer de vragen a tot en met d van opgave 3 indien er twee 
tappers zijn die de klanten parallel bedienen. o 


Beantwoord opnieuw de vragen a tot en met d van opgave 3 indien een 
dorstige na het verlaten van de toog zijn of haar (van hem?) drankje 
drinkt en hij of zij daarna, als de dorst nog niet gelest is en de toog nog 
niet vol is, daar nog één keer plaats neemt om een tweede, tevens laatste, 
drankje te bestellen. 

Indien in het laatste geval de toog wel vol is verlaat de dorstige de kroeg. 
De duur van het ‘drinkproces’ is homogeen verdeeld. o 
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7 In een fabriek komen twee soorten orders binnen volgens een Poisson 
proces. Alle orders ondergaan dezelfde bewerking op machine A. Orders 
van soort 1 verlaten daarna de fabriek terwijl orders van soort 2 nog 
een bewerking ondergaan op machine B. Zolang machine B bezet is, 
hebben orders van soort 2 voorrang op orders van soort 1 bij machine 
A. Is machine B onbezet dan hebben orders van soort 1 bij machine A 
voorrang. De duur van een bewerking van een order op zowel machine A 
als machine B is homogeen verdeeld. 

Bij elke machine is de volgorde waarin de orders van een bepaalde soort 
bewerkt worden FIFO. Om- en insteltijden van de machines zijn verwaar- 
loosbaar. De leiding van de fabriek wil graag weten hoe de gemiddelde 
doorlooptijd van elk soort order afhangt van de combinatie van bewer- 
kingstijden op de 2 machines. 

Maak van deze fabriek een procesbeschrijving. 

Doorloop hierbij de stappen a tot en met d van opgave 3. o 


8 *In een bedrijf worden orders met behulp van een machine verwerkt. De 
orders komen gemiddeld om de 6.5 minuut binnen (de tussenaankomst- 
tijden mogen negatief exponentieel verdeeld verondersteld worden). De 
bewerkingstijd van een order is homogeen verdeeld tussen 5 en 10 minu- 
ten. De volgorde waarin de orders bewerkt worden is FIFO. De machine 
heeft gemiddeld 10 maal per werkdag van 8 uur (een Poisson proces) te 
maken met een storing (defect). De storingen treden op tijdens het bewer- 
ken van een order of als de machine al geplaagd wordt door een storing. 
In het laatste geval zal eerst de reeds aanwezige storing verholpen moeten 
worden en daarna de nieuwe storing. Als een machine bezig is met een 
order bij het optreden van een storing, kan, nadat de storing verholpen is, 
met de order verder gegaan worden alsof er geen storing geweest was. Het 
opheffen van een storing kost 10 tot 20 minuten (homogeen verdeeld). 
De bedrijfsleiding vraagt zich af of ze een andere, snellere maar minder 
betrouwbare, machine zal aanschaffen. De Lawabli ihashite van een order 
zal dan Tide verdeeld zijn tussen 4 en 8 minuten, terwijl het ge- 
middeld aantal storingen per werkdag zal toenemen tot 15. Als criterium 
hierbij zal de gemiddelde doorlooptijd per order gebruikt worden. 

Stel in het kader van deze vraagstelling een procesbeschrijving op voor 
dit bedrijf via de stappen a tot en met d van opgave 3. o 


9 In een ijzermijn zijn 4 graafmachines tegelijkertijd in bedrijf. Deze laden 
rotsblokken met ijzererts erin op vrachtwagens. De vrachtwagens rijden 
hiermee naar een andere plaats op het terrein waar 4 identieke kraak- 
installaties staan opgesteld om het ijzererts uit de rotsblokken vrij te 
maken. 

Nadat een vrachtwagen zijn lading heeft kunnen lossen, rijdt deze via een 
andere weg terug naar de graafmachines om opnieuw gevuld te worden. 
De capaciteit van een graafmachine bedraagt 250 ton/uur. De rijtijd 
van een vrachtwagen van een kraakinstallatie naar de graafmachines is 
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uniform verdeeld tussen 15 en 25 minuten. 

De rijtijd in omgekeerde richting is uniform verdeeld tussen 20 en 40 
minuten. 

Zowel bij de graafmachines als bij de kraakinstallaties staan bij aankomst 
de vrachtauto’s in een wachtrij opgesteld. 

De leiding van de ijzermijn vraagt zich af hoeveel vrachtwagens met een 
laadvermogen van 25 ton minimaal nodig zijn om de dure graafmachines 
ieder gedurende een werkdag van 8 uur voor meer dan 90% bezet te 
houden. Het laden van 1 vrachtwagen kost altijd 6 minuten, het lossen 4. 
Geef een procesbeschrijving van deze ijzermijn, volg daarbij de stappen 
a tot en met d-van opgave 3. 

N.B. Aan het eind van een werkdag staan alle vrachtwagens in een rij 
bij de 4 graafmachines. o 


Hoofdstuk 3 


Simulatievoorbeeld met de hand 


3.1 Inleiding 


Het doel van dit hoofdstuk is inzicht te krijgen in de wijze waarop een simu- 
latie op implementatienivo verloopt. Dit willen we doen aan de hand van een 
handsimulatie. Pas in de volgende hoofdstukken komt het implementeren in 
een programmeertaal aan de orde. 

De handsimulatie zal eerst volgens de eventbeschrijving worden uitgevoerd 
om een duidelijk beeld te geven hoe een en ander in de tijd verloopt. Daarna 
wordt een uitwerking gegeven volgens een procesbeschrijving. 


3.2 Een kwantitatief model van het tanksta- 
tion 


We zullen de handsimulatie baseren op het tankstation van voorbeeld 2.1. 
Doel van de simulatie is hier de gemiddelde wachttijd van de bediende auto’s te 
bepalen waarbij er van wordt uitgegaan dat er geen doorrijders zijn (maximum 
rijlengte p wordt op oneindig gesteld). We zullen daarbij gebruik maken van 
de volgende kwantitatieve gegevens die betrekking hebben op 10 auto’s. 


autonummer : 12345678910 
tussenaankomsttijden :95 12121512 


bedieningstijden : 4563214211 


De bedieningstijd mag pas bekend worden verondersteld als de auto het sys- 
teem binnenkomt. 


3.3 De eventbeschrijving 


We zullen bij het gebruik van de eventbeschrijving alleen de gevolgen van de 
activiteiten aangeven. Hierbij wordt een onderscheid gemaakt tussen gevol- 
gen voor het reêle systeem (= toestandsveranderingen) en gevolgen voor de 
waarnemer (= registraties door middel van hulpvariabelen). 

Bij het tankstation kwamen de volgende eventtypen voor: 


e komt een auto het systeem binnen (Aankomst van een auto), 
e de pomp komt vrij (Vertrek van een auto). 
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De gewenste informatie kan worden verkregen door de individuele wachttijd 
per auto en het aantal bediende auto’s te registreren. 


De gegevens die we bij de handsimulatie moeten bijhouden zijn dan: 


eventtijdstip 

eventtype (A of V) 

tijdstip volgende Aankomst 

tijdstip volgende Vertrek 

POMPVRIJ 

RIJLENGTE 

NBEDIEND (aantal bediende auto’s) 
WACHTTIJDi (wachttijd voor auto i) 


Door gebruik te maken van het stroomschema van figuur 2.8 is de simulatie 
eenvoudig uit te voeren. Zij verloopt als volgt (zie figuur 3.1): 


tijdgrootheden toestandsvar. hulpvariabelen 


eventtype tijdst. tijdst. POMP RIJ NBE- WACHT- 
volg. volg. VRIJ LENG- DIEND TIJDi 
Aankomst Vertrek TE 


‘ 9 se 
A auto 1 14 
V auto 1 14 
A auto 2 15 
A auto 3 17 


0 (auto 1) 


0 (auto 2) 


Sete CO O 


A auto 4 18 
A auto 5 20 
V auto 2 20 
A auto 6 21 
A auto 7 26 


4 (auto 3) 


V auto 3 26 
A auto 8 27 
A auto 9 29 
V auto 4 29 
A auto 10 - 


8 (auto 4) 


10(auto 5) 


ahoaho PBwnwWwhND HFOCCS?S 


A A WD WL W DO NN e Ke 


Figuur 3.1: Handsimulatieresultaten volgens de eventbeschrijving 
(tot en met t = 29) 


We starten op t = 0: 
De variabelen krijgen de initiële waarde. Het eerstvolgende aankomsttijdstip is 
t = 9. De ‘klok’ selecteert het eerstvolgende eventtijdstip (in dit geval t = 9). 


Emel: 
Er wordt vastgesteld of het een Aankomst- of Vertrek-event betreft. In dit ge- 
val Aankomst; het volgende aankomsttijdstip wordt bepaald, het vetrektijdstip 
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wordt bepaald en de variabelen worden veranderd overeenkomstig de eventbe- 
schrijving. | 
Het eerstvolgende eventtijdstip wordt weer door de ’klok’ geselecteerd. 


tala: 

etc. etc. 

Tot slot moet de ’waarnemer’ uit de individuele wachttijden en het aantal 
bediende auto’s nog de gemiddelde wachttijd berekenen. 


3.4 De procesbeschrijving 

Vanwege het quasi-parallel verlopen van de processen van de verschillende com- 
ponenten wordt de handsimulatie wat ingewikkelder dan bij de eventbeschrij- 
ving. 

We gaan uit van de procesbeschrijvingen van figuur 2.14. 


De samenhang in de tijd van de activiteiten AO tot en met A5 van de compo- 
nenten is weergegeven in figuur 3.2. 


generator 
auto1 
auto? 


auto3 


pomp 


wachtrij 


Figuur 3.2: Samenhang activiteiten van de componenten in de tijd. 
De pijlen geven de volgorde van de activiteiten op één tijdstip aan. 


Eee U 
De initialisatie houdt hier in dat op tijdstip t = 0 een component ‘besturing’ 
wordt geactiveerd. Deze component zal op zijn beurt allereerst (ook op t = 0) 
een waarnemer creêren en activeren waardoor hij zelf passief wordt. 

De waarnemer voert geen reele activiteiten uit en zal dus direct weer wor- 
den gedeactiveerd. Hierdoor wordt de component ‘besturing’ weer actief die 
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dan (nog steeds t = 0) een wachtrij creëert en activeert (en daardoor zelf 
gedeactiveerd wordt). 

De wachtrij is initieel leeg (RIJLENGTE = 0) en wordt gedeactiveerd bij 
‘wacht op UITRIJ’. Via de component ‘besturing’ wordt vervolgens de pomp 
gecreeerd en geactiveerd. 

De pomp is initieel niet bezet (POMPVRIJ = TRUE) en wordt gedeacti- 
veerd bij ‘wacht op INRIJ’. Tenslotte wordt via de component ‘besturing’ de 
aankomstgenerator gecreëerd en geactiveerd. 

De aankomstgenerator wordt gedeactiveerd op het punt wacht tot TIME 
= AANKOMSTTIJD (= 9). 

De component besturing wordt nu weer actief en wordt vervolgens meteen 
weer gedeactiveerd. 

Nu is er geen enkele component meer actief. 
Om de handsimulatie voort te zetten moeten we het eerstvolgende tijdstip 
weten waarop er weer een activiteit wordt uitgevoerd. Hiertoe lopen we alle 


opgestarte processen langs en zien dat het eerstvolgende tijdstip (= eventtijd- 
stip) t = 9 is. 


9: 
De aankomstgenerator creéert en activeert een auto en wacht tot de volgende 
aankomsttijd van een auto (t = 14). 

De gegenereerde auto voert zijn proces uit en neemt plaats in de wachtrij 
(RIJLENGTE = 1). Tevens wordt de pomp geactiveerd. Deze haalt hem uit 
de rij (RIJLENGTE = 0), waarbij de wachtrij geactiveerd wordt (nu niet echt 
nodig omdat RIJLENGTE = 0). Daarna, maar wel op hetzelfde tijdstip t = 9, 
start de pomp de bediening (POMPVRIJ := FALSE) en wacht tot de bediening 
voorbij is (t = 13). Vervolgens, nog steeds op t = 9 wordt de auto weer actief 
die dan met zijn proces ‘klaar’ is. Voor t = 9 zijn nu alle activiteiten uitgevoerd. 

Het volgende eventtijdstip wordt geselecteerd (dit behoort bij het proces 
dat het eerst in de tijd aan de beurt is, in dit geval de pomp). 


eb 

De pomp zorgt ervoor dat de auto vertrekt. Het aantal bediende auto’s wordt 
door de waarnemer verhoogd (NBEDIEND := NBEDIEND + 1). De rijlengte 
is 0 en de pomp wacht bij ‘wacht op INRIJ’ waardoor hij passief wordt. 


t = 14: de aankomstgenerator etc. etc. 
De simulatie stopt als er tien auto’s zijn bediend. De waarnemer heeft dit 
aantal bijgehouden. Op grond van de waarde van dit getal zal de pomp op dit 


moment de component ‘besturing’ activeren waardoor de simulatie beéindigd 
wordt. 


Dit betekent dat in figuur 2.14 de procesbeschrijving van ‘besturing’ het 
driehoekje bevat. 


Voor de resultaten zie weer figuur 3.1. 
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3.5 Opgaven 


1 *Voer voor het tankstation een handsimulatie uit volgens de eventbe- 
schrijving voor: 
p=3 
aankomsttijden : 5,1, 2,1, 2,1, 9,6,1, 2 
bedieningstijden : 4, 5, 6, 3, 2, 1, 4, 2, 1, 1 


2 Idem maar nu volgens een activiteitenbeschrijving. oO 


Hoofdstuk 4 


Statistische aspecten van simulatie en 
modelvalidatie 


4.1 Inleiding 


Bij de handsimulatie in het vorige hoofdstuk waren zowel de individuele waar- 
den van de kenmerken van de tijdelijke componenten, te weten de tussenaan- 
komsttijden en bedieningstijden, als hun aantal vooraf bekend. In het algemeen 
zal dit niet het geval zijn. Hoe de waarden voor de kenmerken per individuele 
component dan kunnen worden verkregen wordt behandeld in 4.2. 

Het aantal tijdelijke componenten, of meer algemeen, de duur van een simu- 
latie, hangt direkt samen met de gewenste betrouwbaarheid en nauwkeurigheid 
van de simulatieresultaten. Hierop wordt nader ingegaan in 4.3. 

In 44 tenslotte zal kort aandacht worden besteed aan modelvalidatie, de 
laatste stap voordat met het uitvoeren van de simulatie-experimenten begon- 
nen kan worden. Hiermee is, afgezien van de computerimplementatie, de essen- 
tie van de in figuur 1.2 geschetste aanpak behandeld. 


4.2 Het genereren van tussenaankomsttijden 
en bedieningstijden: trekkingen uit verde- 
lingen 


Voor het genereren van de voor de simulatie benodigde input zijn er in principe 
drie mogelijkheden: 


a. De in werkelijkheid gemeten waarden van de attributen van de compo- 
nenten worden opgeslagen in een bestand waar ze later weer uitgelezen 
worden (zie bijvoorbeeld tabel met getallen voor de 10 auto’s in 3.2). We 
hebben dan te maken met een deterministische input. 

b. De waargenomen waarden van de stochastische variabelen kan men op- 
vatten als trekkingen uit een kansverdelingsfunctie. Uit deze kansverde- 
lingsfunctie (bijvoorbeeld gegeven in histogramvorm) worden bij simula- 
tie trekkingen gedaan. 

c. De waargenomen waarden van de stochastische variabelen kan men op- 
vatten als trekkingen uit een bekende theoretische kansverdelingsfunctie 
(bijvoorbeeld negatief exponentiele verdeling, normale verdeling, Erlang 
verdeling etc.). 
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Voor een aantal veel voorkomende theoretische verdelingsfuncties be- 
staan algoritmes voor het doen van trekkingen tijdens een simulatie. 


In het onderstaande zullen we laten zien hoe aselecte trekkingen uit ver- 
delingen verkregen kunnen worden door eerst random trekkingen uit een ho- 
mogene verdeling (0,1) te realiseren en vervolgens deze randomgetallen met 
behulp van een zogenaamde inverse verdelingsfunctie te transformeren tot een 
trekking uit de gewenste verdeling. 


4.2.1 De pseudo-random generator 


Aselecte getallen kunnen op veel manieren verkregen worden, bijvoorbeeld 
met een zuivere tienkantige dobbeltol. Voor simulatie toepassingen hebben 
we echter veel aselecte getallen nodig die we bij voorkeur op een later tijdstip 
weer moeten kunnen reproduceren. Het genereren van zuivere aselecte getallen 
met behulp van een computer blijkt erg moeilijk te zijn. Wel kunnen bij bena- 
dering reeksen aselecte getallen verkregen worden met behulp van algoritmes 
die eenvoudig op een computer geïmplementeerd kunnen worden. Een dergelijk 
geïmplementeerd algoritme wordt een pseudo-random generator genoemd. 


Het hiervoor aanbevolen basisalgoritme (Shannon 1975, Law and Kelton 
1982, Pidd 1984) staat bekend onder de naam lineaire congruente generator. 

De reeks integer getallen {z;} wordt hierbij gegenereerd door middel van 
onderstaande recursieve betrekking: 


Ligi = (a.z; +c) mod m o E a t DEN 
a,c,m zijn constanten 
zo is de initiële waarde of startwaarde 


random getal r; = z;/m 


Getalvoorbeeld: a = 3,c = 0,m = 5, £o = 4 
De getallenreeks wordt dan: 4,2, 1,3,4,2, etc. 
Voor elke i geldt: 2; < m; de reeks is cyclisch, 
in dit voorbeeld met lengte m — 1. 
De trekkingen op interval (0,1) zijn: … 
0,8; 0,4; 0,2; 0,6; 0,8; 0,4 etc. 


Er is veel onderzoek gedaan naar geschikte (voor)waarden voor a, c en m. 

Er zijn voorwaarden bekend op grond waarvan de getallenreeks ‘een volle- 
dige periodeduur’ heeft, dat wil zeggen elk getal 0,1, 2,3, …, m — 1 komt precies 
één keer voor in de cyclus. 

De keuze van het getal m hangt nauw samen met het getalbereik van de 
computer. Om een zo groot mogelijke periodeduur te halen wordt voor m een 
priemgetal gebruikt. In de praktijk speelt bij de keuze ook de efficiency van 
het rekenalgoritme mee (bijvoorbeeld macht van twee rekent ‘handig’). 
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Law en Kelton doen bijvoorbeeld de volgende aanbeveling voor een 32-bits 
machine: 


m = 2°! — 1 = 2.147.483.647; a=7° =16.807; c=0. 
Binnen SIMULA worden de volgende parameters gebruikt: 
nya a=5'*. c=0 
(merk op dat m hier geen priemgetal is!). 


Bij gebruikmaking van een randomgenerator met een grote cycluslengte, 
waarbij elk integer getal uit de reeks (1,2,3,...,m — 1) één keer in de cyclus 
voorkomt, kan men in principe een willekeurig getal uit die reeks als start- 
waarde kiezen. Indien men ‘tegelijkertijd’ over meerdere random reeksen wil 
beschikken kan men of met meerdere algoritmen gaan werken of met meer- 
dere reeksen gebaseerd op verschillende startwaarden. Bijvoorbeeld indien het 
enige verschil tussen twee te vergelijken systemen bestaat uit een machine die 
per systeem een andere storingsgevoeligheid heeft is het wenselijk dat de ran- 
domreeksen van de overige stochastische grootheden ongewijzigd blijven; met 
andere woorden elke stochastische grootheid moet over een eigen random reeks 
kunnen beschikken. 

Theoretisch bestaat de mogelijkheid dat deze reeksen elkaar overlappen 
(Kleijnen 1986). Bij een grote cycluslengte is de kans hierop echter uiterst (ver- 
waarloosbaar?) klein. Wil men overlap uitsluiten dan bestaan er algoritmen die 
niet-overlappendheid waarborgen of men kan gebruik maken van zogenaamde 
Fishman tabellen waarin geschikte startwaarden verzameld zijn. 

Ook kan men zelf startwaarden verzamelen met behulp van de generator 
door bijvoorbeeld van een zeer lange reeks getallen om de 10° getallen een 
getal te selecteren en dit te gebruiken als element van een verzameling niet- 
overlapveroorzakende startwaarden (indien benodigde reeks < 10°). 


We komen zo tot het volgende overzicht van eisen /wensen ten aanzien van 
een pseudo-random generator (Law and Kelton): 


. aselectheid, 

. reproduceerbaarheid, 

. voldoende grote cycluslengte, 

. meerdere random reeksen, 

. efficiency (zowel qua CPU-tijd als geheugenruimte). 


eo Me T o 
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4.2.2 Trekkingen uit een kansverdelingsfunctie 


Een veelgebruikte methode voor het verkrijgen van aselecte trekkingen uit 
kansverdelingen zullen we toelichten aan de hand van figuur 4.1. 


F(x) 
k, 


aselect getal i 
uit: CDE 


| 

l 

| 

l 

| ERK 
aselecte trekking x uit F 


Figuur 4.1: Een aselecte trekking uit kansverdeling F(x) 
De procedure luidt als volgt: 


a. Bepaal met behulp van een pseudo-random generator een aselect getal r 
uit (0,1), 

b. Los z op uit de vergelijking r = F(x) óf x = F-!(r) waarbij F-! de 
inverse functie van F is. 
De gewenste trekking is dan z. 


Voorbeeld 4.1: 


Gegeven de negatief exponentiéle verdeling met kansdichtheid 


fins i.e 
De kansverdeling is dan: F(z} = f fdt = 1 e7% 
We stellen verder: Flej=r 


Dus: ln(1 — r) = —Ax 


ik -5 -In(1— +) 


Deze laatste uitdrukking mag statistisch gezien ook geschreven worden als: 


Pe jier 


Het uitvoeren van trekkingen uit andere analytische functies of uit discrete 
verdelingen of uit continue verdelingen die gespecificeerd zijn door middel van 
een tabel verlopen in grote lijnen analoog. We merken op dat binnen ver- 
schillende talen, zoals SIMULA, reeds standaard procedures aanwezig zijn om 
aselecte trekkingen uit theoretische verdelingsfuncties te verrichten. 


Statistische aspecten van simulatie en modelvalidatie - 4 45 


4.3 Hoe lang moeten we simuleren: betrouw- 
baarheid van simulatieresultaten 


In het algemeen zal het gedrag van een te onderzoeken systeem varieren als 
functie van de tijd. Bijvoorbeeld de wachttijd bij een kassa van een supermarkt 
zal afhangen van het moment van de dag. 

De periode die we simuleren moet overeenstemmen met de voor ons in- 
teressante periode van het reële systeem. Het door een simulatierun verkregen 
gedrag van een systeem als functie van de tijd voor zo’n periode hangt sterk van 
het toeval af omdat het is gebaseerd op de wisselende duur van de activiteiten 
van de afzonderlijke componenten. Het gedrag binnen een run kan als het ware 
worden opgevat als een trekking uit de verzameling mogelijke gedragspatronen 
van het systeem over de betreffende periode. 

Om een zekere betrouwbaarheid van het gedrag als functie van de tijd te 
verkrijgen moeten we meerdere simulatieruns gaan uitvoeren. Voor elke simu- 
latierun bepalen we het gedrag van het systeem op een gegeven aantal mo- 
menten. Vervolgens worden de resultaten van de afzonderlijke runs voor de 
overeenkomstige momenten gemiddeld. 


Met betrekking tot de te simuleren periode zullen we drie gevallen onder- 
scheiden: 


a. Simulatie van een systeem dat zich in een zogenaamde stationaire toe- 
stand bevindt die eventueel voorafgegaan werd door een opstartfase. In 
een stationaire toestand zijn de eigenschappen van de relevante groothe- 
den statistisch gezien onafhankelijk van de tijd. 

b. Simulatie van de opstartfase van een systeem waarbij de duur van de 
opstartfase vooraf niet bekend is. 

c. Simulatie van een systeem gedurende een van tevoren vaststaande peri- 
ode. Bijvoorbeeld 1 werkdag van 8 uur. 


We zullen nu eerst situatie a verder uitwerken. 


Stel met betrekking tot het voorbeeld van het tankstation dat we ons in een 
stationaire situatie bevinden waarbij we geïnteresseerd zijn in de gemiddelde 
wachttijd van de auto’s. 

Stel verder dat we de gemiddelde wachttijd verkregen zouden hebben 
met behulp van n opeenvolgende wachttijden van auto’s uit dezelfde run: 
Kea oe, En): 

De vraag is nu of deze berekende gemiddelde wachttijd voldoende betrouw- 
baar is om op grond daarvan beslissingen te nemen. 


De serie wachttijden kan worden opgevat als een steekproef, met steekproef- 
gemiddelde z: 


n 
ber ak 
Em iN Ti 
nos 
$1 
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en met steekproefvariantie s?: 


Deet > n) 
Eti teel 


Om met behulp van deze grootheden een betrouwbaarheidsinterval voor 
= Ez te kunnen bepalen is het noodzakelijk dat 2,,25,...,2, onderling 

onafhankelijk zijn en afkomstig zijn uit dezelfde verdeling (Een stochastische 
variabele x wordt aangegeven als x; de operator E staat voor verwachtings- 
waarde). 

Echter in het algemeen, zo ook in het geval van het tankstation zullen 
Z1, £9,... Zp niet onderling onafhankelijk zijn! Een lange wachter zal in het 
algemeen buren hebben die ook lange wachters zijn. 

We kunnen wel een betrouwbaarheidsinterval voor u = Ex berekenen als 
we over meerdere onafhankelijke trekkingen van 7 zouden kunnen beschikken. 
(Immers ook EZ = p). 

We kunnen hier aankomen door een lange simulatierun te verdelen in een 
aantal subruns. 

Stel de subruns genummerd: 0,1,2,...,k. 

Subrun 7 start met de toestand van het systeem zoals die door subrun i — 1 is 
achtergelaten. De nulde subrun is de zogenaamde aanlooprun waarop verderop 
nader wordt ingegaan. 

Alle subruns (behalve de nulde) worden even lang gekozen. De subrun- 
lengte moet zo groot zijn dat de subrungemiddelden bij benadering onderling 
onafhankelijk zijn. 

De onderlinge afhankelijkheid kan worden uitgedrukt met behulp van de 
autocorrelatie COR(2;, 2:4; ). 

Omdat de autocorrelatie het sterkst tot uiting komt in de Afhankelijkheid 
van elkaar opvolgende subrungemiddelden wordt slechts de le orde autocorre- 
latie beschouwd (j = 1). Hierop is de Von Neumann ratio q gebaseerd (Kleijnen 


1986). 


n—1 
> & ~ 2,41)" 
nsi 

n 


> Ez) 


nsi 


QS 


n = aantal subruns 
z; = gemiddelde van subrun 7 

T = het gemiddelde van de subrungemiddelden 

Indien de gemiddelden x van de subruns onderling onafhankelijk zijn en 


4 
N(p, 07) verdeeld kan worden bewezen dat q bij benadering N (2,4 als aba = 7 ) 


verdeeld is. 
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We zullen de Von Neumann ratio q gebruiken als criterium voor de beoor- 
deling van onderlinge onafhankelijkheid van subruns. 


Stel nu dat we op grond van de waarde van q de subrungemiddelden 
(Z,,Z,...,Z,) onderling onafhankelijk mogen veronderstellen. 

Eén subrungemiddelde kan opgevat worden als een trekking uit een onbe- 
kende verdeling. 

Het gemiddelde van de subrungemiddelden zullen we aanduiden met Z en 
de variantie van de k subrungemiddelden weer met s?. 

Volgens de centrale limietstelling geldt dat de som van k trekkingen uit een 
onbekende verdeling (k voldoende groot) bij benadering opgevat mag worden 
als een trekking uit een normale verdeling. 


Zo vinden we met een betrouwbaarheid (1 — a), het volgende betrouwbaar- 
heidsinterval voor p: 


T- Jg t- (5) <u<E+ Fg t-i (=) 


waarin: 
a = overschrijdingskans 
p = de verwachting van z 
T = het gemiddelde van de subrungemiddelden 
s = standaardafwijking van de k subrungemiddelden 


k = aantal subruns 


Q i f 
Sr (5) = waarde af te lezen uit student's T-verdeling 


— = standaardafwijking van T) 


Vk 


We zien dus dat het aantal subruns van een simulatierun wordt bepaald 
door de gewenste nauwkeurigheid en betrouwbaarheid van de uiteindelijke 
uitspraken. 

Er bestaan variantiereducerende technieken waardoor men met een kleiner 
aantal subruns even nauwkeurige uitspraken kan doen. In dit boek wordt daar 
niet verder op ingegaan (Kleijnen 1986). 


Er zal nu worden aangegeven hoe we in principe experimenteel de minimaal 
benodigde lengte van een aanlooprun kunnen bepalen alsmede de minimale 
benodigde lengte van de subruns opdat de subrungemiddelden onderling onaf- 
hankelijk verondersteld mogen worden. Daarmee wordt tevens het in het begin 
van deze paragraaf onderscheide punt b behandeld. De betrouwbaarheid van 
de resultaten van punt c kan eenvoudig worden bepaald door herhaling van 
runs met de gegeven simulatieduur. 
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4.3.1 Experimentele bepaling lengte aanlooprun 


We zullen in deze paragraaf de aanlooprunproblematiek visueel inzichtelijk 
maken. 

In de praktijk zal men bij de bepaling van de lengte van de aanlooprun 
veelal werken met de resultaten van proefruns, of met vuistregels gebaseerd op 
inzichten bijvoorbeeld verkregen uit experimenten van onderstaand type. 

De experimenten hebben betrekking op het tankstation nu met een onbe- 
perkte wachtruimte om het aanloopeffect beter zichtbaar te maken. Hierbij is 
aangenomen dat de tijden tussen de aankomsten bij het tankstation negatief 
exponentieel verdeeld zijn (met parameter À = 1/5,5) en de bedieningstijden 
constant (5 eenheden). 

Voor deze situaties is de bezettingsgraad (dit is de verhouding tussen aan- 
komstintensiteit en maximaal mogelijke bedieningsintensiteit) 


1/5,5 
- i = 1 
r 1/5,0 0,9 


Een voor de hand liggende aanpak lijkt te zijn om de waarde van de gewenste 
grootheid (doorlooptijd) voor de opeenvolgende auto’s grafisch uit te zetten en 
te kijken of deze grootheid een ‘stationaire toestand’ bereikt. Dit is gedaan in 
figuur 4.2A. 

Hierin is geen aanloopeffect zichtbaar. Dit aanloopeffect is misschien wel 
aanwezig maar wordt dan volledig overheerst door de grote variaties in de indi- 
viduele doorlooptijden. In de figuren is te zien dat er ‘regelmatig’ een wachttijd 
van 0 tijdseenheden optreedt. 

(De doorlooptijd is dan gelijk aan de bedieningstijd; volgens de theorie 
geldt dit gemiddeld voor 1—r = 0,09 gedeelte van de totaal beschouwde tijd). 


Om de variaties enigszins te onderdrukken en om de tijdas compacter te 
kunnen weergeven is de aanlooprun verdeeld in aansluitende stukken (zoge- 
naamde subruns) van ieder 100 auto’s. Per subrun is de gemiddelde doorloop- 
tijd (dit) berekend. De zo verkregen gemiddelde doorlooptijd per subrun is 
uitgezet in figuur 4.2B. Ook deze resultaten zijn erg fluctuerend, zonder duide- 
lijk zichtbaar aanloopeffect. 


Om de variaties nog verder te onderdrukken zijn van 100 verschillende aan- 
loopruns zoals weergegeven in figuur 4.2B (dus ieder bestaande uit 30 subruns 
van elk 100 auto’s) de gemiddelde doorlooptijden van de corresponderende 
subruns gemiddeld. De zo verkregen resultaten voor het gemiddelde van de 
gemiddelde doorlooptijden (dlt) staan weergegeven in fig. 4.2 C,D,E voor drie 
verschillende bezettingsgraden. 

We kunnen nu voor r = 0,91 en r = 0,82 een duidelijk aanloopgedeelte 
onderkennen. Voor alle drie de gevallen is duidelijk een stationaire fase zicht- 
baar. 

Voor elke r-waarde kan worden afgeleid na hoeveel subruns het subrunge- 
middelde ‘de stationaire waarde’ bereikt heeft. 
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We merken op dat de gevonden ‘stationaire waarden’ overeenstemmen met 


de hieronder berekende theoretische waarden. 


E(dlt) = E(wachttijd) + E(bedieningstijd) 
r hk 
(sas + 1) x E(bedieningstijd) 


= 30,3 (voor r = 0,91 en bedieningstijd = 5) 
= 15,6 (voor r = 0,82 en bedieningstijd = 4,5) 
= 4,13 (voor r = 0,5 en bedieningstijd = 2,75) 


In figuur 4.2C wordt na 300 à 400 auto’s de ‘stationaire waarde’ bereikt. 
Figuur 4.2F geeft de experimenteel gevonden relatie tussen de lengte van de 
aanlooprun en de bezettingsgraad (nu echter gebaseerd op een subrunlengte 


van 25 auto’s). 


Hieruit blijkt dat de benodigde lengte van de aanlooprun sterk toeneemt 


bij toenemende bezettingsgraad. 
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Figuur 4.2: Enkele onderzoekresultaten met betrekking tot de lengte van de 
aanlooprun. dlt = gemiddelde doorlooptijd; r = bezettingsgraad. De 
stippellijn in figuur C, D en E geeft de verwachtingswaarde aan. 
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4.3.2 Experimentele bepaling lengte subrun 


De problematiek van de bepaling van de noodzakelijke lengte van de subrun 
voor het geval de simulatie uit een lange run bestaat, wordt hier weer toegelicht 
aan de hand van het tankstation. 

De tussenaankomsttijden worden weer negatief exponentieel verondersteld; 
de bedieningstijd homogeen tussen 2 en 8 tijdseenheden. De bezettingsgraad r 
kan worden ingesteld door de keuze van de waarde van de gemiddelde tussen- 
aankomsttijd. 

We gaan er vanuit dat er een voldoende lange aanlooprun geweest is zodat 
we ons in een stationaire situatie bevinden. We willen de betrouwbaarheid van 
de verkregen waarde voor de gemiddelde doorlooptijd in de stationaire situa- 
tie bepalen aan de hand van de gemiddelde doorlooptijden van de verschil- 
lende subruns. De subrungemiddelden dienen hiervoor onderling onafhankelijk 
te zijn. Als criterium hiervoor zal de Von Neumann ratio worden gehanteerd. 
Bij de uitvoering van het experiment moet nog een keus gemaakt worden voor 
de subrunlengte en het aantal subruns per run. 

In figuur 4.3A zijn voor 10 verschillende subrunlengtes, variërend van 25 tot 
1600, de bijbehorende g-waarden (gebaseerd op 100 subruns per run) uitgezet. 

Theoretisch geldt dat er sprake is van onderlinge onafhankelijkheid met een 
betrouwbaarheid van 95% indien: 


q>2-1,645.0, 


Omdat het aantal subruns in figuur A gelijk is aan 100 (n = 100) luidt het 
criterium hier 


q> 1,67 


Vergelijken we de experimenteel bepaalde q-waarden met dit criterium dan 
blijkt dat hier subruns met een lengte vanaf 200 onderling onafhankelijk ver- 
ondersteld mogen worden. 


Bij herhaling van dit experiment (met andere random reeksen) blijkt er 
een vrij grote variatie in het verloop van de curven te zitten. Om toch tot een 
richtlijn te komen voor de minimaal noodzakelijke subrunlengte is het gewenst 
dat de variaties meer onderdrukt worden. Dit is gedaan door met een groter 
aantal subruns te werken (n = 2000). 

In figuur 4.3B en 4.3C zijn de zo verkregen resultaten voor r = 0,8 resp. 
r = 0,9 weergegeven. 


In figuur 4.3D zijn een aantal van dergelijke resultaten samengevat. Hieruit 
blijkt dat de benodigde subrunlengte sterk afhankelijk is van de bezettings- 
graad. Voor een bezettingsgraad van ca. 0,85 is de benodigde subrunlengte al 
ca. 1000 auto’s. | 


De hiervoor beschreven resultaten geven aan hoe men in principe inzicht 
kan krijgen in de te gebruiken lengtes van de aanlooprun en subruns. Volgens 
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Law en Kelton (1982) geven resultaten van elementaire één-loketsystemen zo- 
als hier behandeld (zij werken overigens met exponentieel verdeelde tussen- 
aankomsttijden en bedieningstijden) reeds goede indicaties voor de benodigde 
subrunlengtes bij meer complexe simulatiemodellen. 
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subrunlengte 


bezettingsgraad 


Figuur 4.3: Enkele onderzoeksresultaten met betrekking tot de subrunlengte 
ten behoeve van onderling onafhankelijke subruns. 
r = de bezettingsgraad; n = aantal subruns; per subrunlengte is een run 
uitgevoerd bestaande uit n subruns van deze lengte. 
De horizontale stippellijnen geven de theoretische ondergrens aan van 
het 95% betrouwbaarheidsinterval voor q. 


Tot slot willen we beklemtonen dat het hiervoor behandelde als ‘illustratie’ 
bedoeld is en dat men in praktische situaties minder rigoreus te werk behoeft 
te gaan. Men zou zich dan kunnen beperken tot het bepalen van de q-factor 
en nagaan of deze aan het gestelde criterium voldoet, waarbij het aanbeveling 
verdient het aantal subruns gelijk te kiezen aan 100. 


4.4 Modelvalidatie en experimentele resulta- 


ten 


We zullen de systeemschets van figuur 2.2 gebruiken als leidraad bij de model- 
validatie. 

[Iet is allereerst van belang dat het statistisch gedrag c.q. de waarden van 
de omgevings- en stuurvariabelen geverifieerd zijn. 

Daarnaast is een juiste keuze van de begintoestand, al dan niet verkregen 
met behulp van een aanlooprun, van belang. 

Tenslotte moeten de met het model verkregen waarden van de uitgangsva- 
riabelen overeenstemmen met mogelijk bekende waarden afkomstig uit de prak- 
tijk c.q. resultaten uit de theorie. Praktijkgegevens hebben doorgaans betrek- 
king op bestaande of historische situaties, dus modelvalidatie kan dan slechts 
voor deze situaties plaats vinden. 

Ook vergelijking met theoretische resultaten is dikwijls slechts ten dele 
mogelijk (waarom zouden we anders gaan simuleren?). Dit vergelijken kan op 
twee manieren: 
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a. Door het gedrag van het model in extreme situaties te beschouwen. Voor 
extreme situaties is dikwijls wel een analytische oplossing bekend. Deze 
oplossing(en) kunnen worden gebruikt als ondergrens/bovengrens voor 
de beoordeling van de resultaten van het model. 

b. Door het model te vereenvoudigen. 

Hierdoor kunnen soms situaties worden gecreeerd waarvoor weer analyti- 
sche oplossingen bekend zijn die gebruikt kunnen worden voor het testen 
van een deel van het volledige model. 


De validatie geschiedt veelal met proefruns die worden opgezet volgens de in 
4.3 geschetste aanpak. 

Bovendien leveren dergelijke proefruns resultaten die dikwijls gebruikt kun- 
nen worden bij de planning van de serie definitieve simulatie experimenten. Bij- 
voorbeeld bij de bepaling van de lengte van de aanlooprun en de subruns, en het 
aantal uit te voeren subruns om een zekere betrouwbaarheid /nauwkeurigheid 
van de resultaten te bereiken. 


Voordat men de definitieve serie experimenten gaat plannen is het gewenst 
dat men inzicht heeft in de gevoeligheid van het model. Dat wil zeggen dat 
men een indruk moet hebben in welke mate verandering van de waarden van 
diverse ingangsvariabelen de waarden van de uitgangsvariabelen beïnvloeden. 
Ook dit kan men weer onderzoeken met proefruns, waarbij telkens de waarde 
van slechts een variabele wordt gevarieerd. 

Op grond van voorgaande resultaten kan tenslotte een serie (definitieve) 
experimenten gepland en uitgevoerd worden opdat men de gewenste resultaten 
met de gewenste nauwkeurigheid tot zijn beschikking krijgt. 

Mede op grond van deze resultaten wordt vervolgens besloten hoe men het 
reele probleem zal gaan oplossen. 


4.5 Opgaven 


1 *Waarom zien we in figuur 4.2.E geen duidelijke aanloopverschijnselen? 
m 


2 *Beargumenteer het verloop van de curve in figuur 4.3.D. o 


3 *Geef één alternatief voor het gebruik van één lange run indien we 
geinteresseerd zijn in een stationaire situatie. o 


Hoofdstuk 5 


Implementatie van de 
beschrijvingswijzen in Pascal 


5.1 Inleiding 


Het doel van dit hoofdstuk is om na te gaan in hoeverre de op verschillende 
beschrijvingswijzen gebaseerde gekwantificeerde modellen eenvoudig geimple- 
menteerd kunnen worden in een taal als PASCAL. Dit zullen we doen voor het 
tankstation uit hoofdstuk 2. 


5.2 Implementatie van de activiteitenbeschrij- 
ving in Pascal 


In 2.4 zijn voor het tankstation de drie activiteitsklassen en het bijbehorende 
stroomschema weergegeven. Het activiteiten-stroomschema van figuur 2.6 lijkt 
qua structuur erg op het event-stroomschema van figuur 2.8. In het kader 
van dit boek verwijzen we daarom wat betreft de implementatieaspecten in 
PASCAL naar de hierna volgende implementatie van de eventbeschrijving. 


5.3 Implementatie van de eventbeschrijving in 
Pascal 


We gaan hierbij uit van de resultaten zoals gepresenteerd in 2.5. Het hieruit 
afgeleide pseudocode-programma is weergegeven in figuur 5.1. 

Bij de verdere uitwerking van het pseudocode-programma zullen een aan- 
tal problemen die bij ‘de implementatie van alle drie de beschrijvingswijzen 
optreden, opgelost moeten worden: 


a. Wat betekent ‘not klaar’ precies, met andere woorden hoe lang moeten 
we simuleren? 

b. Hoe genereren we tussenaankomsttijden en bedieningstijden? 

c. Hoe implementeren we een wachtrij? 


Op aen b zijn we reeds ingegaan in het vorige hoofdstuk. Met betrekking 
tot b zullen we aannemen dat uit de analyse van waarnemingen is gebleken 
dat de tussenaankomsttijden van auto’s goed beschreven kunnen worden door 
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middel van een negatief exponentiële verdeling met een gemiddelde van 4 mi- 
nuten (met andere woorden het aankomstproces is een Poissonproces met 0.25 
gebeurtenissen per minuut). Tevens zullen we aannemen dat de bedienings- 
tijden bij de pomp beschreven mogen worden door middel van een homogene 
verdeling tussen 1 en 6 minuten. 

Met betrekking tot c merken we op dat de in figuur 5.1 genoemde wachtrij 
dient voor de opvang van de tijdelijke componenten na aankomst. De wacht- 
rij kunnen we implementeren als een array W. De lengte van array W moet 
minstens gelijk zijn aan het maximale aantal auto’s dat op een tijdstip in het 
systeem kan staan te wachten. Deze lengte moet vooraf bekend zijn! Het uit 
de wachtrij gaan van een auto houdt in dat de overige aanwezige auto’s een 


plaats ‘opschuiven’, dus dat W; := Wj41,2 =1,2,..., RIJLENGTE. 


Start + initialisaties; 
WHILE not klaar DO 
BEGIN selecteer volgende event(klok); 
IF eventklasse=aankomst THEN 
BEGIN genereer volgende aankomsttijdstip; 
IF rijlengte < p THEN 
BEGIN plaats de auto in de wachtrij; 
IF de pomp vrij is THEN 
BEGIN haal de auto uit de wachtrij, 
registreer de wachttijd, 
schuif overige auto’s een plaats door, 
bezet de pomp, 
genereer tijdstip vertrek, 
END; 
END; 
ELSE ridoor; 
END; 
IF eventklasse=vertrek THEN 
BEGIN verwijder de auto van de pomp, 
maak de pomp vrij, 
IF de wachtri is niet leeg THEN 
BEGIN haal eerste auto uit de wachtrij, 
registreer de wachttijd, 
schuif overige auto’s een plaats door, 
bezet de pomp, 
genereer tijdstip vertrek; 
END; 
END; 
END; 
uitvoer gemiddelde wachttijd; 


Figuur 5.1: Een eventbeschrijving van het tankstation in pseudocode 
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Het probleem van het vooraf bekend moeten zijn van de maximale rijlengte 
en het ‘doorschuiven’ is te voorkomen door gebruik te maken van zogenoemde 
lijsten. 

Een lijst kan men voorstellen als een ketting bestaande uit schakels die, met 
uitzondering van de eerste en laatste schakel, zodanig aan elkaar gekoppeld 
zijn dat iedere schakel precies één voorganger en één opvolger heeft. In elke 
schakel wordt bijgehouden wie zijn voorganger en opvolger zijn. Men kan op 
elke willekeurige plaats in de ketting nieuwe schakels toevoegen én bestaande 
schakels verwijderen. Bij het afbeelden van een wachtrij als een ketting komt 
elke tijdelijke component overeen met een schakel, waarin informatie over die 
component kan worden opgeslagen. 

Veel van de huidige programmeertalen beschikken over mechanismen om 
dergelijke kettingen op efficiënte wijze te implementeren. Men noemt het dan 
een datastructuur en de acties die men op de datastructuur kan uitvoeren 
operaties. 

Alhoewel men in PASCAL zelf lijsten met behulp van het recordtype kan 
definiëren zullen we dat terwille van de eenvoud in het voorbeeld niet doen. 


We zijn nu in staat om het pseudocode programma van figuur 5.1 te de- 
tailleren tot een volledig PASCAL programma. 

Hieronder volgen de omschrijvingen van de programma-variabelen terwijl 
in figuur 5.3 het programma wordt gegeven. 


variabele betekenis 


. ARRAANK 

. ARRET 

. EVTYPE 

. GEMTAT 

. GEMWACHT 
. GWS 

. GWT 

. GWTKWT 


- IJ 

. INF 

. NSUBRUN 

. NAANKOMST 

. NDOORRIJDEN 


. NBEDIEND 
. NWACHT 

. MAXRIJL 

. OG,BG 


array met aankomsttijden van auto’s 
array met eventtijdstippen 

type van het eerstvolgende eventtijdstip 
gemiddelde tussenaankomsttijd 

somwt /nwacht 

som gemm. wachttijden 

gem. wachttijd over de subruns 

som van de kwadraten van gem. wachttijd over 
de subruns 

hulpteller 

een zeer groot getal 

subrun teller 


-aantal aankomsten tot nu toe 


teller van het aantal auto’s die geen plaats 
vinden op het emplacement 

aantal bediende auto’s 

teller van het aantal gemeten wachttijden 
maximale lengte wachtrij 
ondergrens/bovengrens van het bedieningstijden 
interval | 
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. POMPVRIJ boolean variabele; TRUE als de pomp vrij is, 
anders FALSE 

. RIJLENGTE actuele lengte van de wachtrij 

. SOMWT som van de wachttijden 

. SOMKWT som van kwadraten van wachttijden 

. SUBRUNL totaal aantal te verwerken auto’s per subrun 

. TIME systeemtijd 

. VARWACHTGEM variantie gem. wachttijd over de subruns 

. WACHTTIJD wachttijd van een individuele auto 


Figuur 5.2: De in figuur 5.3 gebruikte variabelen met hun betekenis 


PROGRAM TANKSTATION (INPUT , OUTPUT) ; 

VAR I,NSUBRUN,MAXRIJL, INF ,NWACHT , NBEDIEND , SUBRUNL , NDOORRIJDEN ,EVTYPE, 
RIJLENGTE : INTEGER; 
TIME,WACHTTIJD, SOMWT , GEMTAT , OG , BG , GWS , GWT , GWTKWT , VARWACHTGEM, 
GEMWACHT : REAL; 
POMPVRIJ : BOOLEAN; 
ARRET : ARRAY[O..1] OF REAL; 
ARRAANK : ARRAY[1..100] OF REAL; 


PROCEDURE BEZET; 
VAR J : INTEGER; 
BEGIN WACHTTIJD :=TIME-ARRAANK [1]; 
SOMWT : =SOMWT+WACHTTIJD; 
RIJLENGTE : =RIJLENGTE-1; 
IF RIJLENGTE > O THEN 
BEGIN FOR J:=1 TO RIJLENGTE DO ARRAANK[J]:=ARRAANK[J+1] END; 
POMPVRIJ:=FALSE; 
ARRET [1] :=TIME+0G+ (BG-0G) *RANDOM; 
END; 


BEGIN (*INITIALISATIES*) 

WRITE(’GEEF DE WAARDE VAN MAXRIJL : °);READLN (MAXRIJL) ; 
WRITELN(’GEEF SUBRUNLENGTE,GEMTAT,OG,BG :’);READLN(SUBRUNL) ; 
READLN (GEMTAT) ; READLN (OG) ; READLN (BG) ; 
NSUBRUN : =0 ; INF: =10000 ; NWACHT : =0 ; NBEDIEND: =0 ; NDOORRIJDEN:=0; 
RIJLENGTE: =0; SOMWT:=0.0;GWS:=0.0;GWT:=0.0;GWTKWT:=0.0; 
VARWACHTGEM:=0.0; GEMWACHT:=0.0;WACHTTIJD:=0.0; 
POMPVRIJ :=TRUE; ARRET(0] :=0.0; ARRET [1] :=INF; 
TIME: =0; ARRET [0] :=TIME-GEMTAT*LN (RANDOM) ; 
(*BESTURING AANTAL SUBRUNS*) 
WHILE NSUBRUN < 11 DO 
BEGIN (*BESTURING SUBRUNLENGTE*) 

WHILE NBEDIEND < SUBRUNL DO 

BEGIN (*KLOK*) 

TIME:=INF; 
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FOR I:=0 TO 1 DO IF ARRET[I] < TIME THEN 
BEGIN EVTYPE:=1;TIME:=ARRET[I] END; 
ARRET[EVTYPE] : =INF; 
IF EVTYPE=0 THEN 
BEGIN (*EVENTKLASSE = AANKOMST*) 
ARRET [0] :=TIME-GEMTAT*LN (RANDOM) ; 
IF RIJLENGTE < MAXRIJL THEN 
BEGIN RIJLENGTE: =RIJLENGTE+1 ; 
ARRAANK [RI JLENGTE] :=TIME; 
IF POMPVRIJ THEN BEZET 
END 
ELSE NDOORRIJDEN :=NDOORRIJDEN+1 
END; 
IF EVTYPE=1 THEN 
BEGIN (*EVENTKLASSE = VERTREK*) 
NBEDIEND :=NBEDIEND+1 ; 
POMPVRIJ:=TRUE; 
IF RIJLENGTE > 0 THEN BEGIN NWACHT :=NWACHT+1; 


BEZET; 
END; 
END; 
END; 
(*BEREKENING + UITVOER RESULTATEN*) 
WRITELN (’SUBRUNNUMMER = ’ ,NSUBRUN:2); 


IF NWACHT > O THEN GEMWACHT: =SOMWT/NWACHT 
ELSE GEMWACHT:=0; 


WRITELN(’GEM.WACHTTIJD SUBRUN = ’ ,GEMWACHT:5:2); 
WRITELN(’AANTAL DOORRIJDERS SUBRUN = ’ ,NDOORRIJDEN: 4); 
WRITELN ; 


IF NSUBRUN > O THEN 

BEGIN GWS:=GWS+GEMWACHT; 
GWTKWT : =GWTKWT+GEMWACHT*GEMWACHT ; 

END; 

IF NSUBRUN = 10 THEN 

BEGIN GWT:=GWS/10.0; 
WRITELN(’GEM.WACHTTIJD TOTAAL = ’,GWT); 
VARWACHTGEM : =(GWTKWT-GWS*GWS/NSUBRUN) / (NSUBRUN-1) ; 
WRITELN(’?VAR.GEM.WACHTTIJD TOTAAL = ’,VARWACHTGEM) ; 

END; 

NSUBRUN : =NSUBRUN+1 ; NBEDIEND: =0 ; SOMWT :=0.0;NWACHT:=0; 

NDOORRIJDEN:=0; GEMWACHT:=0.0;WACHTTIJD:=0.0; 

END; 
END. 


Figuur 5.3: Het Pascal-programma voor het tankstation 
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Toelichting op het programma: 


a. Merk op dat in figuur 5.1 een deel van de eventbeschrijving ‘aankomst’ 
identiek is aan een deel van de eventbeschrijving ‘vertrek’. Dit identieke 
gedeelte is geïmplementeerd als de procedure BEZET’. 

b. De array ARRET bevat de tijdstippen van het eerstvolgende event ‘aan- 
komst’ (= ARRET[0]) en ‘vertrek’ (= ARRET[1]). De ‘klok’ selecteert 
steeds het eerstkomende event. De systeemtijd TIME wordt dan door de 
‘klok’ gelijkgemaakt aan het tijdstip van het ‘eerstkomende event’. Het 
zal duidelijk zijn dat na het opstarten van het systeem (op TIME = 0) 
het eerstvolgende event van het type ‘aankomst’ moet zijn. 

c. De systeemtijd TIME geeft de opeenvolgende eventtijdstippen waarop de 
toestand van het systeem verandert. Tussen de opeenvolgende eventtijd- 
stippen verandert de toestand van het systeem niet; deze tussenliggende 
tijd kunnen we bij simulatie overslaan. Alhoewel in het systeem de events 
tijdloos verlopen zal bij simulatie het bepalen van de daarbij optredende 
toestandsveranderingen wel (computer)tijd kosten. Het onderscheid tus- 
sen systeemtijd en computertijd is als volgt te illustreren: 


event n systeemtijd TIME 
siebe wan aeg in uren) 


bebat ‘ing toestandsverander ing computert ijd 
ten gevolge van event n (bijvoorbeeld in msec.) 


d. RANDOM is een functie in PASCAL voor het genereren van random 
getallen. (Zie 4.2.1). 


Een simulatie bestaat hier uit 11 subruns van elk 500 auto’s waarbij de nulde 
subrun als aanlooprun wordt gebruikt. 

Per subrun wordt de gemiddelde wachttijd en het aantal doorrijders berekend. 
De resultaten van de 11 uitgevoerde subruns staan in de tabel op de volgende 
pagina. 

Uit de gemiddelde wachttijden van de 10 subruns, waarvan wordt aangenomen 
dat deze onderling onafhankelijk zijn, wordt het gemiddelde en de variantie 
hiervan berekend. 
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subrunnr. gem. wachttijd aantal doorrijders 
4,81 
5,04 
5,37 
4,87 
4.90 
5,16 
5,01 
5,12 
5,26 
4,88 


0 
1 
2 
4 
5 
6 
7 
8 
9 
0 


Het gemiddelde van de gem. wachttijden van run 1 t/m 10: ¥ = 5,10. 

De variantie van de gem. wachttijden van run 1 t/m 10 is: s = 0,35. 

Met 7 en s kan nu een betrouwbaarheidsinterval voor u = Ex worden berekend. 
Volgens de formules van vorig hoofdstuk ligt u met een betrouwbaarheid van 
95% binnen het interval: 


Bie to(0,025) < u < T+ a to(0, 025) 


io’ 10 


4,85 < u < 5,35 


5.4 [Implementatie van de procesbeschrijving 
in Pascal 


Met betrekking tot procesbeschrijvingen ligt de implementatie in PASCAL 
moeilijker. Bekijken we het stroomschema van het tankstation van figuur 2.14 
dan zien we dat het mogelijk moet zijn de uitvoering van een proces (pro- 
gramma) tijdelijk te onderbreken (zie symbolen ‘wacht tot’ en ‘wacht op’). 
Eveneens is het wenselijk dat de onderlinge afstemming tussen de verschil- 
lende processen (quasi-parallelliteit) eenvoudig geïmplementeerd kan worden. 
PASCAL beschikt standaard niet over de benodigde faciliteiten om dit direct 
te implementeren. 


Hetzelfde geldt ook voor andere talen zoals FORTRAN, ALGOL, COBOL. 


Meer algemeen kunnen we nu de volgende eisen/wensen met betrekking tot 
een taal voor de implementatie van procesbeschrijvingen formuleren: 


a. Het kunnen implementeren van een procesbeschrijving als een module; 
dit wil zeggen dat van een componentklasse zowel de procesbeschrijving 
als de data met betrekking tot die componentklasse deel uitmaken van 
dezelfde module. 
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b. Het eenvoudig kunnen genereren van de afzonderlijke componenten (elk 
met eigen attribuutwaarden en individuele procesbeschrijving) uitgaande 
van de procesbeschrijving en attributen van de componentklasse. 
(Vergelijk recordoccurence versus recordtype). 

c. Het kunnen beschikken over lijstfaciliteiten bijvoorbeeld voor een een- 
voudige implementatie van wachtrijen. 

d. Het kunnen beschikken over een eenvoudige implementatie van de ‘klok’, 
waarbij de eventtijdstippen automatisch door het implementatiehulpmid- 
del worden afgeleid uit de individuele procesbeschrijvingen. 

e. Het kunnen beschikken over een eenvoudige implementatie van ‘quasi- 
parallelliteit’. 


Een taal die aan bovengenoemde eisen voldoet is de reeds klassieke taal 
SIMULA die het onderwerp van het volgende hoofdstuk zal vormen. 


5.5 Opgaven 
l Verifieer dat het Pascalprogramma uit figuur 5.3 overeenstemt met het 
pseudocode-programma van figuur 5.1. o 


2 *In het Pascalprogramma kan de maximale rijlengte interactief worden 
opgegeven. Wat is de maximaal toegestane waarde van p? o 


3 Relateer de onder 5.4 genoemde eisen aan de specificaties van de proces- 
beschrijving van het tankstation uit hoofdstuk 2. o 


Hoofdstuk 6 


Introductie in de taal SIMULA 


6.1 Inleiding 


Dit hoofdstuk is zodanig opgezet dat het aansluit op de eisen /wensen die aan 
het eind van het vorige hoofdstuk zijn opgesteld met betrekking tot een taal 
voor implementatie van een procesbeschrijving. Tevens is getracht dit hoofd- 
stuk zo op te zetten dat het ook als een introductie in de taal SIMULA gebruikt 
kan worden zonder enige kennis van de voorafgaande vijf hoofdstukken. 

De hier gegeven introductie in de taal SIMULA kan interessant zijn voor 
diegenen die bijvoorbeeld: 


e meer achtergrondinformatie willen hebben met betrekking tot informatie- 
systeem ontwerpmethoden als ‘Jackson Structured Development’ (Jack- 
son 1983, Cameron 1986), 

e achtergrondinformatie willen hebben over bepaalde aspecten van ‘Expert 
Systems’ zoals ‘frames’ (Harmon and King 1985), 

e een minder technische inleiding in de taal SIMULA op prijs stellen dan 
die gegeven is in bijvoorbeeld het standaardwerk van Birtwistle et al. 
(1973, 1984), 


e een (klassiek) voorbeeld willen zien van een object-georiënteerde taal. 


Hoe de in 5.4 genoemde wensen ondersteund kunnen worden met beschikbare 
faciliteiten binnen SIMULA is weergegeven in figuur 6.1. 


In 6.2 wordt het class concept geïntroduceerd. Een class kan opgevat worden 
als een recordtype gecombineerd met een stuk programma dat daarop operaties 
kan uitvoeren. Het class concept sluit aan bij de in hoofdstuk 2 behandelde 
procesbeschrijving van een componentklasse. 

In 6.3 wordt het begrip subclass of gespecialiseerde class behandeld. Dit is 
met name van belang voor een goed begrip van de structuur van een aantal 
door SIMULA beschikbaar gestelde faciliteiten. 

In 6.4. wordt de implementatie van wachtrijen in de vorm van lijsten be- 
schreven. Tevens wordt behandeld hoe het quasi-parallel verlopen van pro- 
cessen ondersteund wordt door de subclass PROCESS. Ook wordt hier kort 
ingegaan op de implementatie van het klokmechanisme. 

Vervolgens worden in 6.5 enkele taalkundige aspecten van SIMULA be- 
handeld, terwijl in 6.6 op de binnen SIMULA beschikbare statistische functies 
wordt ingegaan. 

Tot slot volgt in 6.7 een SIMULA-implementatie van het tankstation (van 
voorbeeld 2.1). 
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Implementatie gewenst van: beschikbare faciliteiten 
binnen SIMULA: 


- data + operaties in één module - (sub)class concept 
(attributen + procesbeschrijving) 


- wachtrij (‘lijst’) - gespecialiseerde class — 
(LINKAGE CLASS HEAD) 
(LINKAGE CLASS LINK) 


- quasi-parallelliteit - gespecialiseerde class 


(LINK CLASS PROCESS) 


- klokmechanisme - gespecialiseerde class 
(zgn. eventketting 
opgebouwd met behulp van 
LINKAGE CLASS HEAD 
LINKAGE CLASS LINK) 


Figuur 6.1: Een overzicht van het gebruik van beschikbare faciliteiten binnen 
SIMULA ten behoeve van het implementeren van procesbeschrijvingen 


Een aantal voorbeelden en figuren in dit hoofdstuk zijn gebaseerd op het werk 
van Birtwistle et al. (1984) en van Papazoglou et al. (1984). 


6.2 Het class concept 


Een (object)class kan men zich voorstellen als een recordtype gecombineerd 
met een stuk programma (de zogenaamde classbody) eventueel inclusief proce- 
dure(s). Alle variabelen (d.w.z. parameters en locale variabelen) die bij creatie 
van een object beschikbaar komen, worden in een record van het betreffende 
type opgeslagen. Dit record is boekbaar met behulp van een pomer, in SI- 
MULA een reference variabele geheten. 

Een laatste overeenkomst met PASCAL is, dat er meerdere objecten (ook 
wel genoemd ‘occurences’, ‘voorkomens’, ‘exemplaren’) van eenzelfde object- 
class kunnen worden gecreëerd, zoals meerdere records van eenzelfde recordtype 


in PASCAL. 


Bij creatie van een nieuw object in SIMULA wordt de classbody meteen 
uitgevoerd. Nadat alle statements binnen de body uitgevoerd zijn (later zal 
blijken dat ook onderbrekingen mogelijk zijn) kan deze niet meer opnieuw 
worden doorlopen. Het record met variabelen blijft echter bestaan zolang er 
een pointer naar verwijst. 


We beginnen in voorbeeld 6.1 met een CLASS declaratie genaamd ‘voer- 
tuig’. Dit is een type definitie, er ‘gebeurt dus nog niet echt wat’. 


Introductie in de taal SIMULA -6 


Voorbeeld 6.1: declaratie class voertuig 


CLASS voertuig(bouwjaar, gewicht); INTEGER bouwjaar; REAL gewicht; 
BEGIN REAL belasting, gemsnelheid; 

INTEGER kmstand; 

REF (voertuig) voorganger; 


IF bouwjaar < 1970 OR gewicht < 1000.0 

THEN belasting := 500.0 

ELSE belasting := 0.5*gewicht; 

gemsnelheid := 0.0; kmstand:=0; 
END**voertuig** ; 


De hier gedeclareerde class bevat geen procedures. De class voertuig kent een 
6-tal attributen of variabelen: 2 parameters (bouwjaar en gewicht) en een 4-tal 
locale variabelen (belasting, gemsnelheid, kmstand en voorganger), die geza- 
menlijk de recordomschrijving vormen. Bouwjaar en gewicht worden parame- 
ters genoemd omdat bij creatie van een object van deze klasse hiervoor waarden 
moeten worden opgegeven. ‘Voorganger’ is een REFerence variabele (pointer) 
die naar een ander object, hier toevallig van dezelfde class voertuig, kan wijzen. 
In de classbody wordt de belasting voor een gecreéerd voertuig berekend. In 
de terminologie van hoofdstuk 2 komt de class-body overeen met de proces- 
beschrijving en het class-record met de attributen van een componentklasse. 
De actuele waarden van de variabelen bepalen de actuele toestand van een 
individueel object van die class. De body (of activiteitenlijst) beschrijft de 
activiteiten die een object zelf uitvoert. 


Van de class voertuig kan nu een object gecreéerd en geactiveerd worden 
door middel van de opdracht NEW. 


Voorbeeld 6.2: creatie en activatie van een object van de class voertuig 


NEW voertuig(1921, 1800.0); 


bouwjaar 


gewicht 1800.0 

belasting 500.0 

gemsnelheid 0.0 } class-record 
kmstand 0 


voorganger 
IF bouwjaar < 1970 OR gewicht < 1000.0 
THEN belasting := 500.0 

ELSE belasting := 0.5 * gewicht; 
gemsnelheid := 0.0; kmstand := 0; 


} class-body 


In bovenstaande figuur zijn de waarden van de variabelen van het gecreéerde 
object weergegeven evenals diens ‘class-body’. Het is voor de gebruiker net alsof 
elk gecreëerd object over een eigen class-body beschikt (in werkelijkheid wordt 
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dit maar één keer opgeslagen; het SIMULA-systeem zorgt ervoor dat vanuit 
elk gecreëerd object de bijbehorende class-body toegankelijk is). 

Na de instructie NEW wordt hier meteen begonnen met de uitvoering van 
de classbody waarbij de actuele parameterwaarden worden ingevuld. Nadat alle 
statements van de body zijn uitgevoerd kan men de waarden van de variabelen, 
opgeslagen in het record, alleen nog bereiken en veranderen via een pointer die 
naar het betreffende object verwijst. Voor iedere pointer geldt dat deze slechts 
naar één type object kan verwijzen. Dit object-type moet bij de declaratie van 
de pointer vermeld worden. 

Bijvoorbeeld: 


REF(voertuig) eend, volvo, mijnauto; 


waarbij eend, volvo, mijnauto pointers zijn die kunnen verwijzen naar objecten 
van de class voertuig. 

De initiële waarde van de pointers is NONE, dit wil zeggen er is nog niet 
aangegeven naar welke objecten van de class voertuig door hen verwezen wordt. 
Dit geven we symbolisch als volgt weer: 


vend 
mijnauto NONE 


De voertuigen waarnaar met de naam eend respectievelijk volvo verwezen 


wordt, worden bijvoorbeeld gecreëerd en geactiveerd met: 


eend :- NEW voertuig(1963, 800.0); 
volvo :- NEW voertuig(1984, 1250.0); 


Het teken :— staat voor toekenning van een object aan een referentievariabele, 
zoals := staat voor toekenning van een waarde aan een variabele. 


Zo ontstaat de volgende situatie: 


bouwjaar 
gewicht 800.0 
belasting 500.0 
gemsnelheid 0.0 
kmstand 0 

voorganger NONE 

IF’....etc. 


Introductie in de taal SIMULA -6 67 


bouwjaar 
gewicht 1250.0 
belasting 625.0 
gemsnelheid 0.0 
kmstand 0 
voorganger NONE 
IF ….etc. | 


mijnauto NONE 
Stel dat nu het volgende statement wordt uitgevoerd: 


mijnauto :- volvo; 


Dan verandert de situatie als volgt: 


bouwjaar 
gewicht 800.0 
belasting 500.0 
gemsnelheid 0.0 


kmstand 0 
voorganger NONE 
IF....etc. 


bouwjaar 
gewicht 1250.0 
belasting 625.0 
gemsnelheid 0.0 
kmstand 0 

voorganger NONE 

IF....etc. 


Via een referentievariabele kan de waarde van een attribuut van een object 
worden verkregen door middel van de punt-notatie (net als bij records in PAS- 
CAL). Hiervan is gebruik gemaakt in: 


IF mijnauto.belasting > 600.0 THEN mijnauto :- eend; 


Het is niet altijd nodig om voor elk object een afzonderlijke referentievariabele 
te declareren. Door in een class een referentievariabele op te nemen, zoals voor- 
ganger in de class voertuig, kan men zelf eenvoudig een ketting van voertuigen 
maken. Als we nu over de gegevens met betrekking tot al onze vroegere auto’s 
willen kunnen blijven beschikken, dan kan dat door bij aankoop van een nieuwe 
auto als volgt te handelen. 


Stel de oude situatie was de volgende: 
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bouwjaar 
RPR en 
voorganger 


bouwjaar 
s+. @tc. 
voorganger 


en de verandering is: 


volvo :- NEW voertuig(1985, 1250.0); 
volvo.voorganger :- mijnauto; 
mijnauto :- volvo; 


dan wordt de nieuwe situatie: 


pend | onnan 


ebt 
voorganger 


bouwjaar 
‚€€. 


voorganger 


voro [bende 


ete: 
voorganger 


nauto | * | 


We zien dat het object dat in de oude situatie met volvo werd aangeduid niet 
meer met behulp van een pointer bereikbaar is, en dus nutteloos geworden is. 
Binnen SIMULA worden niet bereikbare objecten automatisch verwijderd uit 
het systeem (zogenaamde ‘garbage collection’). In de nu volgende voorbeelden 
zullen we de schematische tekeningen van objecten achterwege laten. 


Referentievariabelen kunnen onderling worden vergeleken met het symbool 
== (beide wijzen naar hetzelfde object) of =/= (beide wijzen niet naar het- 
zelfde object). Voorbeeld: 


IF mijnauto == eend THEN OUTTEXT ("het kon erger"); 
IF mijnauto =/= volvo THEN OUTTEXT ("jammer") ; 


SIMULA kent ook de negatie NOT zodat de laatste opdracht ook geschreven 
kan worden als: 


IF NOT(mijnauto == volvo) THEN OUTTEXT ("jammer"); 
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De parameters en locale variabelen van objecten kunnen worden vergeleken 
met behulp van het gebruikelijke = teken. Bijvoorbeeld: 


IF eend.belasting = volvo.belasting THEN OUTTEXT ("oneerlijk"); 


De toestand van een object kan in principe ook van buitenaf veranderd worden. 
Bijvoorbeeld door het volgende statement: 


volvo.bouwjaar := 1700; 


Dit geeft aanleiding tot een ongewenste toestand aangezien er in 1700 nog geen 
volvo gebouwd was. 

Om dit soort ongewenste toestandsveranderingen te voorkomen en om er 
voor te zorgen dat de procesbeschrijving en dus de programma’s waaruit deze is 
opgebouwd overzichtelijk blijven, verdient het aanbeveling alle veranderingen 
van waarden van attributen van een object van buitenaf, plaats te laten vinden 
d.m.v. binnen dat object gedeclareerde functies of procedures. 

In deze functies/procedures legt men dan niet alleen de wijze vast hoe 
de attributen gewijzigd moeten worden maar ook de voorwaarden waaronder 
evenals het toegestane bereik van de attribuutwaarden (constraints). Het louter 
inspecteren van de waarden van attributen kan men zonder enig gevaar wel met 
behulp van de puntnotatie uitvoeren aangezien hierdoor de toestand van het 
bijbehorende object niet (ongewenst) kan veranderen. 


Stel dat voor een voertuig de variabelen kmstand en gemsnelheid aan het 
eind van elke rit moeten worden aangepast. Dan kunnen we de class voertuig 
uitbreiden met een procedure ‘verplaats’ die voor deze aanpassingen zorgt. Als 
bijvoorbeeld ook vaak de leeftijd van de auto gebruikt wordt, kan voor het 
berekenen hiervan een functie worden gedeclareerd. 

In voorbeeld 6.3 is het voertuig van voorbeeld 6.1 uitgebreid met de proce- 
dure verplaats en de functie leeftijd. 

Merk op dat binnen een functie een waarde wordt toegekend aan een va- 
riabele met dezelfde naam als de functie. 

Hierbij moet het type van de functie overeenkomen met het type van deze 
variabele. 


Merk op dat een procedure of functie ook als een attribuut van een object 
wordt beschouwd, zodat deze net als een variabele met de puntnotatie kan 
worden benaderd. 

Mijnauto kan nu eenvoudig verplaatst worden d.m.v. de procedureaanroep: 


mijnauto.verplaats(100.0, 2.0); 


Hierdoor wordt de kmstand met 100 verhoogd en de gemiddelde snelheid wordt 
50. De ouderdom van mijnauto in 1985 kan eenvoudig bepaald worden via 


ouderdom := mijnauto.leeftijd(1985); 


70 6 - Introductie in de taal SIMULA 


Voorbeeld 6.3: declaratie class voertuig met procedure en functie 


CLASS voertuig(bouwjaar, gewicht); INTEGER bouwjaar; REAL gewicht; 
BEGIN REAL belasting, gemsnelheid; 

INTEGER kmstand; 

REF (voertuig) voorganger ; 


PROCEDURE verplaats(afstand, tijd); REAL afstand, tijd; 

BEGIN kmstand :=kmstand+afstand; 
gemsnelheid:=afstand/tijd; 

END; 


INTEGER PROCEDURE leeftijd(jaar); INTEGER jaar; 
BEGIN IF jaar > bouwjaar 

THEN leeftijd:=jaar-bouwjaar 

ELSE leeftijd:=0; 
END; 


IF bouwjaar < 1970 OR gewicht < 1000.0 

THEN belasting:=500.0 

ELSE belasting:=0.5*gewicht; 

gemsnelheid:=0.0; kmstand: =0; 
END**voertuig** ; 


6.3 Specialisatie: subclasses 


Stel nu dat er niet alleen sprake is van voertuigen, zoals beschreven in voorbeeld 
6.3, maar dat er ook bijzondere voertuigen voorkomen bijvoorbeeld vrachtwa- 
gens. Voor een vrachtwagen zijn niet alleen alle eigenschappen van een voertuig 
van toepassing maar bovendien de volgende ‘attributen’: 


e (de parameter) assental, 
(de variabele) lading, 

(de procedures) laad en los, 
(de functie) asdruk. 


Men zegt wel dat vrachtwagen een specialisatie is van voertuig of omgekeerd 
dat voertuig een generalisatie is van vrachtwagens en niet-vrachtwagens. 

Het komt meer voor dat bijzondere begrippen gevormd worden uit meer 
algemene. Men spreekt dan van specialisatie-hiërarchieën. In SIMULA is het 
mogelijk specialisatie-hiérarchieén te vormen door de naam van de algemene 
‘class’ als prefix te plaatsen voor de declaratie van de subclass. Zo kan de 
subclass vrachtwagen eenvoudig worden gevormd uit de class voertuig zoals 
weergegeven in voorbeeld 6.4. 
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Voorbeeld 6.4: declaratie class vrachtwagen door middel van prefixing met 
behulp van de class voertuig 


voertuig CLASS vrachtwagen(assental); INTEGER assental; 
BEGIN REAL lading; 


PROCEDURE laad(vracht); REAL vracht; 
BEGIN lading:=lading+vracht END; 


PROCEDURE los(vracht); REAL vracht; 
BEGIN IF vracht < lading 


THEN lading:=lading-vracht 
ELSE lading:=0.0; 
END; 


REAL PROCEDURE asdruk; 
BEGIN asdruk:=(gewicht+lading)/assental END; 


lading:=0.0 
END**vrachtwagen** ; 


Hierna volgen enige declaraties en opdrachten waarbij de subclass vrachtwagen 
voorkomt: 


REF (vrachtwagen) daf; 

daf :- NEW vrachtwagen(1975, 8000.0, 3); 
daf.verplaats(500.0, 8.0); 

daf .laad(2000.0); 

IF daf.asdruk > 2000.0 THEN waarschuwing; 


bouwjaar 
gewicht 8000.0 
belasting 4000.0 
gemsnelheid 62.5 
kmstand 500 
voorganger NONE 
assental 3 
lading 2000.0 


body en procedures specifiek voor vrachtwagen 


Meer algemeen: Stel dat class B een subclass is van class A. 
Declaratie: 


CLASS A(FPA)..... ; 
A CLASS B(FPB)..... : 


FPA en FPB zijn de formele parameters van class A respectievelijk class B. 
Creatie van een nieuw object van type class A hebben we in het voorgaande 
steeds voorgesteld als: 
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PA :- NEW A(waarden FPA); 


ZE 


Binnen SIMULA wordt bij creatie van een nieuw object van het type class B 
automatisch ook een nieuw object van type class A gecreëerd: deze zijn on- 
losmakelijk met elkaar verbonden. Bij de aanroep moet men daarom zowel de 
parameterwaarden behorende bij class A als die behorende bij class B aange- 
ven, en wel als volgt: 


PB :- NEW B(waarden FPA, waarden FPB); 


object voor type B 


Zoals bij een niet-prefixed class meteen na aanmaak van een object de body 
doorlopen wordt, zo zal dit ook bij de prefixed class gebeuren en wel in de 
volgorde class A - class B, dus beginnend bij de hiërarchisch hoogste. 

Voor de parameters, de locale variabelen en de functies/procedures, (dus 
de attributen) van class A en class B geldt dat deze als het ware in een groot 
record worden opgenomen: de combinatie van de twee afzonderlijke records A 
en B. 


De door SIMULA beschikbaar gestelde hulpmiddelen zijn gestructureerd 
volgens het specialisatie concept. Deze hulpmiddelen zijn opgenomen in een 
soort bibliotheek (class SIMULATION). Hierover kan worden beschikt door een 
simulatieprogramma te ‘prefixen’ met het woord SIMULATION (zie voorbeeld 
6.12). 


6.4 Systemclass SIMULATION 


De belangrijkste binnen de systemclass SIMULATION beschikbare classes zijn 
LINKAGE, LINK, HEAD en PROCESS. 

De eerste drie kunnen gebruikt worden om lijsten te implementeren, de 
vierde bij implementatie van procesbeschrijvingen. 


1. De class LINKAGE biedt een basisstruktuur om circulaire lijsten te im- 
plementeren. 

2. De class LINK bevat faciliteiten om elementen van een circulaire lijst op 
te kunnen vatten als componenten van een wachtrij. 

3. De class HEAD maakt het mogelijk om één element van een circulaire 
lijst te beschouwen als de ‘beheerder’ van de wachtrij. 

4. Binnen de class PROCESS zijn faciliteiten gedefinieerd om objecten 
quasi-parallel hun body’s te kunnen laten uitvoeren. 
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De specialisatie-hierarchie van de genoemde classes is in figuur 6.2 weergegeven. 


LINKAGE vergelijk: VOERTUIG 
toenemende 
specialisatie 


VRACHTWAGEN 


PROCESS 


Figuur 6.2: Een schets van de hiërarchische structuur 
van de systemclass SIMULATION 


6.4.1 Classes LINKAGE, LINK en HEAD 


Een geschikt hulpmiddel voor het implementeren van onder andere wachtrijen 
is de dubbele, circulaire lijst (two way circular list). Omdat in zo’n lijst elk ele- 
ment een verwijzing heeft naar diens voorganger en opvolger kan men deze lijst 
in twee richtingen doorlopen zonder dat men een begin of een eind tegenkomt 


(Figuur 6.3). 


Figuur 6.3: Een dubbele circulaire lijst bestaande uit vijf elementen S 


Een dergelijke implementatie van een lijst wordt ook wel een ketting genoemd, 
opgebouwd uit schakels. 


De class LINKAGE biedt de faciliteiten om de ketting in twee richtingen 
te doorlopen. 


Om een lijst als implementatie van bijvoorbeeld een wachtrij te kunnen ge- 
bruiken moet er een begin en een eind aan de lijst onderkend kunnen worden. 
Daarom doorbreken we de ketting door één schakel te specialiseren tot beheer- 
schakel (HEAD) en de overige schakels tot zogenaamde linkschakels (LINK), 
zie figuur 6.4, waarin HS de beheerschakel en LS de linkschakels weergeven. 
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Figuur 6.4: Een dubbele circulaire lijst bestaande uit 
de beheerschakel HS en vier linkschakels LS 


In SIMULA zijn de class LINKAGE en de subclasses LINKAGE CLASS HEAD 
en LINKAGE CLASS LINK standaard beschikbaar. 


In figuur 6.5 is een dubbele circulaire lijst-meer gedetailleerd weergegeven. 


De ketting bestaat uit een HEAD met verwijzers naar de eerste en de laatste 
schakel van de ketting, respectievelijk suc (successor) en pred (predecessor) 
genaamd, en een verzameling linkschakels, ook met verwijzers suc en pred. 


Via de onderstaande binnen de class LINKAGE gedefinieerde procedures kan 
men een ketting ‘doorlopen’: 


1. REF(LINK) PROCEDURE SUC; 
2. REF(LINK) PROCEDURE PRED; 


Deze twee procedures leveren een pointer naar de opvolger respectievelijk de 
voorganger van een bepaalde schakel in de ketting en zijn beschikbaar via de 
puntnotatie. Bijvoorbeeld L2 — L1.SUC, waarbij L1, L2 van het type LINK 
zijn, heeft als resultaat dat L2 verwijst naar de opvolger van L1. Indien het 
resultaat geen linkschakel oplevert, dus niet van het type REF(LINK) is, levert 
dit statement voor L2 NONE op. (Dit vanwege REF(LINK) voor de PROCE- 
DURE SUC EN PRED). 


De class HEAD bevat een vijftal procedures die betrekking hebben op de bij- 
behorende ketting: 


1. REF(LINK) PROCEDURE FIRST; 
levert een verwijzing naar de eerste linkschakel in de ketting, mits de 
ketting niet leeg is, anders de waarde NONE, 

2. REF(LINK) PROCEDURE LAST; 
levert een verwijzing naar de laatste linkschakel in de ketting, mits de 
ketting niet leeg is, anders de waarde NONE, 
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subclass subclass 
met prefix met prefix 
LINK LINK 


subclass 
met prefix 
eerste link- LINK Laatste link- 
schakel schakel 


Figuur 6.5: Voorbeeld van een kettingstruktuur binnen SIMULA bestaande 
uit een object van de class HEAD en twee objecten van de class LINK. 
Het derde object van de class LINK maakt geen deel uit van de ketting. 
M.b.v. pointer X is deze bereikbaar. 
Voor het bovenstaande zijn de volgende declaraties nodig: 
REF(HEAD) H; 
REF(B) X; 
LINK CLASS B. 
De subclass B bevat het class-record en de class-body zoals gedefinieerd 
door de gebruiker. | 


3. INTEGER PROCEDURE CARDINAL; 
levert het aantal linkschakels in de ketting, 
4. BOOLEAN PROCEDURE EMPTY; 
levert de waarde TRUE als de ketting leeg is (dit wil zeggen geen link- 
schakels bevat) en anders de waarde FALSE, 
5. PROCEDURE CLEAR; 
verwijdert alle linkschakels uit de ketting. 


De procedures kunnen weer met behulp van de puntnotatie benaderd worden. 


Voorbeeld: 


76 6 - Introductie in de taal SIMULA 


REF(HEAD) H; 

H :- NEW HEAD; 

H.CLEAR; 

OUTINT(H.CARDINAL, 4) (commando voor het uitprinten 
van H.CARDINAL, een integer getal, 
waarvoor 4 posities beschikbaar zijn) 


De class LINK zorgt ervoor dat de class die van de prefix LINK wordt 
voorzien de eigenschappen van een linkschakel krijgt. 


Voor het manipuleren met linkschakels bevat LINK een viertal procedu- 
res (hieronder wordt uitgegaan van de declaraties REF(LINK) L1, L2; 
REF(HEAD) H; REF(LINKAGE)x): 


1. PROCEDURE OUT: 
L1.OUT verwijdert object Ll (dat van (een subclass van) class LINK 
moet zijn) uit de ketting waarvan het deel uitmaakt. Indien L1 zich niet 
in een ketting bevindt gebeurt er niets. Een LINK-object kan zich slechts 
in één ketting tegelijk bevinden. 

2. PROCEDURE INTO(H); 
L1.INTO(H) roept eerst L1.0UT aan en voegt vervolgens L1 als laatste 
linkschakel toe in ketting H. 

3. PROCEDURE PRECEDE(x); 
L1.PRECEDE(L2) roept eerst L1.0UT aan en voegt vervolgens L1 toe 
aan de ketting waarvan L2 deel uitmaakt en wel als voorganger van L2. 
Als L2 niet in een ketting zit is het effect hetzelfde als L1.OUT. Merk op 
dat L1.PRECEDE(H) hetzelfde effect heeft als L1.INTO(H). 

4. PROCEDURE FOLLOW (x); 
Analoog aan procedure PRECEDE met als verschil dat door L1.FOL- 
LOW(L2) L1 de opvolger van L2 wordt. 


Met behulp van de systemclasses HEAD en LINK kunnen in het geval van 
het tankstation van voorbeeld 2.1 (zie figuur 2.14) de auto’s en de wachtrij 
eenvoudig worden beschreven, zoals weergegeven in voorbeeld 6.5 waarbij nog 
geen rekening is gehouden met de interactie tussen de componentklasse ‘auto’ 
en ‘pomp’. 


(TIME in voorbeeld 6.5 is een standaard functieprocedure, zie 6.4.2, en geeft 
op elk moment de systeemtijd aan) 


De aankomst van een auto wordt gegenereerd door de opdracht: 
NEW auto; 


Hierdoor wordt een object van de CLASS auto gecreëerd en geactiveerd. 
Dit object initialiseert zelf zijn aankomsttijd, berekent zijn bedieningstijd en 
neemt, mits er ruimte is op het emplacement, plaats in de wachtrij. 
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Voorbeeld 6.5: De procesbeschrijving van ‘auto’ en ‘wachtrij’ in SIMULA 


LINK CLASS auto; 
BEGIN REAL aankomsttijd, bedieningstijd; 


REAL PROCEDURE wachttijd; 
BEGIN wachttijd:= TIME-aankomsttijd 
END; 


aankomsttijd:= TIME; 

bedieningstijd:= trekking uit homogene verdeling; 

IF wachtrij.CARDINAL < maxrijl THEN INTO(wachtrij); 
END**auto** ; 


REF (HEAD) wachtrij; 
REF (auto) klant; 
INTEGER maxrijl; 
maxrijl:= 5; 

wachtrij :- NEW HEAD; 


a ke 


[klant [NONE 


maxrijl | 5 


Het uit de rij nemen van de eerste auto in de figuur op de volgende pagina 
wordt beschreven door: 


IF NOT (wachtrij.EMPTY) THEN 

BEGIN klant :- wachtrij.FIRST; (zie stippellijn in figuur) 
klant.OUT; 

END; 


6.4.2 Class PROCESS 


De tot nu toe behandelde (sub)classes hebben alle de eigenschap dat de body 
van objecten hiervan meteen na creatie van het object wordt uitgevoerd (ge- 
activeerd). Dit gebeurt in een ononderbroken executie van de statements van 
de body. Men kan zo dus niet twee objecten tegelijkertijd (parallel) ‘actief’ la- 
ten zijn. Dit is echter wel noodzakelijk voor bijvoorbeeld procesbeschrijvingen 
waarin synchronisaties met de systeemtijd (“wachten tot of gedurende”) of met 
andere procesbeschrijvingen (“wachten op’) voorkomen. 
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CE | LINKAGE 


HEAD 


LINKAGE 


aankomsttijd = . 


bedieningstijd=.. 


De class PROCESS maakt het nu mogelijk objecten quasi-parallel actief te 
laten zijn. Dat wil zeggen men kan de uitvoering van de body (activiteitenlijst) 
van een object onderbreken en op een later tijdstip hervatten. Meer algemeen, 
men kan de afhandeling van de activiteiten van de verschillende objecten naar 
wens indelen (schedulen). Hiertoe moet men de class waartoe dit object behoort 
voorzien van de prefix PROCESS. 

Omdat de class PROCESS een subclass is van de class LINK (zie figuur 
6.2), hebben objecten van de class PROCESS tevens alle eigenschappen van 
de class LINK. 

De class PROCESS bevat een variabele EVTIME (eventtime), waardoor 
aan elk PROCESS object een (event)tijdstip toegekend kan worden. Voor alle 
objecten met een waarde voor EVTIME wordt door het SIMULA systeem een 
speciale ketting onderhouden waarin de objecten naar opklimmende waarde 
van EVTIME gesorteerd zijn. Deze ketting is de zogenaamde eventketting en 
elk object daarin is een eventnotitie. 

Bij elke eventnotitie hoort precies één PROCESS-object dat op het be- 
treffende moment geactiveerd moet worden. Het SIMULA systeem zorgt voor 
de koppeling hiertussen door middel van een pointer van een object uit de 
eventketting naar het bijbehorende PROCESS-object (zie figuur 6.6). 
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Iedere haak in de ketting stelt een bepaald eventtijdstip voor. Alle PROCESS- 
objecten die niet passief of terminated (zie hierna) zijn, zijn in de ketting 
opgehangen aan een van de in chronologische volgorde gesorteerde haken. 

Het tijdstip behorende bij een haak bepaalt het tijdstip waarop het object 
weer actief zal worden. 

De linkerhaak behoort bij de systeemtijd TIME en hieraan hangt het actieve 
proces. Is dit proces afgehandeld (terminated of suspended) en bevat deze haak 
geen andere PROCESS-objecten meer, dan wordt deze haak verwijderd en de 
eerstvolgende haak is aan de beurt (de systeemtijd springt naar het volgende 
eventtijdstip). 


Het eerste object in de eventketting wordt het CURRENT ob ject genoemd. 
De status van dit object wordt aangeduid met actief, omdat de uitvoering van 
de opdrachten van zijn activiteitenlijst nu wordt voortgezet. 


Het current object kan zijn actieve status op drie manieren verliezen: 


1. HOLD(t) 
De waarde van EVTIME van het object wordt met t verhoogd. Daardoor 
krijgt het object een andere plaats in de eventketting. Zijn status luidt 
nu opgeschort (suspended, zie object A in fig. 6.7B). 
HOLD(t) kan worden opgevat als de implementatie van het onderstaande 
specificatie symbool uit figuur 2.12 (wachten tot of gedurende): 


HOLD Ct) 


2. Door een PASSIVATE opdracht wordt een object uit de eventketting 
genomen. EVTIME van dit object heeft nu geen waarde meer, de status 
van het object is passief (zie fig. 6.7C). 

PASSIVATE kan worden opgevat als de implementatie van het onder- 
staande specificatie symbool uit figuur 2.12 (wachten op): 


PASSIVATE 
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3. Nadat alle statements van de body zijn uitgevoerd krijgt het object 
(evenals alle niet-PROCESS objecten) de status klaar (terminated). 


In de stroomschema’s gesymboliseerd door (zie figuur 2.12): 


klaar 


Het SIMULA systeem ruimt van tijd tot tijd alle objecten op, die klaar zijn en 
waarnaar geen enkele referentie meer bestaat (garbage collection). Dit betekent 
dat het door deze objecten gebruikte geheugen weer vrij komt. 

Een opgeschort object wordt vanzelf weer actief als het de voorste in de 
eventrij geworden is. Een passief object E, waarnaar een pointer verwijst, kan 
weer actief worden doordat een ander object een ACTIVATE E opdracht uit- 
voert. Daardoor wordt object E current (helemaal vooraan in de eventketting 
geplaatst) en krijgt EVTIME van object E dezelfde waarde als EVTIME van 
het vorige current object (zie fig. 6.7D). 

In stroomschema’s wordt ACTIVATE gesymboliseerd door (zie figuur 2.12): 


ACTIVATE — — — — > 


Als een PROCESS object gecreéerd wordt, krijgt het de status passief, zodat 
een expliciete ACTIVATE opdracht nodig is voordat met uitvoering van de 
body begonnen wordt. 


Raakt de eventketting leeg dan resulteert dat in een runtime error, de si- 
mulatie stopt. 


In onderstaand overzicht zijn alle standaard procedures die specifiek be- 
trekking hebben op PROCESS objecten opgenomen (ze zijn gedefinieerd in de 
class SIMULATION): 


1. REF(PROCESS) PROCEDURE CURRENT; 
levert een verwijzing naar het voorste object in de eventketting. 

2. REAL PROCEDURE TIME; 
levert de actuele waarde van de systeemtijd. 

3. PROCEDURE HOLD(t); REAL t; 
maakt dat het current object opgeschort wordt tot tijdstip TIME + t 
(t > 0). Als dat tijdstip is aangebroken wordt de volgende opdracht uit 
de activiteitenlijst van het object uitgevoerd. 

4. PROCEDURE PASSIVATE; 
verwijdert het current object uit de eventketting (waardoor het passief 
wordt) en gaat verder met het nieuwe current object. Als de eventketting 
leeg wordt ontstaat een runtime error. 
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5. PROCEDURE WAIT(s); REF(HEAD) s; 
het current object wordt achterin ketting s geplaatst en voert een PAS- 
SIVATE opdracht uit. Ketting s is niet de eventketting. 

6. PROCEDURE CANCEL(x); REF(PROCESS) x; 
PROCESS object x wordt uit de eventketting genomen en wordt passief. 
Het effect is overeenkomstig PASSIVATE, met dien verstande dat PAS- 
SIVATE alleen door het betreffende object zelf kan worden uitgevoerd. 


De beschikbare (RE)ACTIVATE statements zijn: 


Ta. ACTIVATE x; 
x wordt het nieuwe current object. De systeemtijd blijft onveranderd. De 
opdracht heeft alleen effect als x passief is. 

Tb. REACTIVATE x; 
x wordt current, ook als x actief of opgeschort is. 

7c. [RE]ACTIVATE x AT t [PRIOR] 
x wordt in de eventketting geplaatst met EVTIME = t. Als er een op- 
geschort object is met EVTIME = t dan wordt x daarachter geplaatst, 
tenzij de optie PRIOR is vermeld. 

7d. [RE]JACTIVATE x DELAY t [PRIOR] 
equivalent met AT TIME + t. 

Te. [RE]ACTIVATE x BEFORE y 
Als y een actief of opgeschort object is dan wordt x voor y in de event- 
ketting geplaatst met dezelfde EVTIME als y. 

Tf. [REJACTIVATE x AFTER y 


als 7e, maar nu achter y. 


Ook deze procedures en statements kunnen aan de hand van een figuur zoals 
6.7 geillustreerd worden. 

Voor de procedures HOLD, PASSIVATE en WAIT geldt dat ze betrekking 
hebben op het object waarin ze zijn opgenomen. Indien ze gebruikt worden 
m.b.v. de puntnotatie, dan geldt dat 


objectnaam.procedurenaam 


betrekking heeft op het object dat met de betreffende objectnaam geidentifi- 
ceerd wordt. Voor de instructies ACTIVATE, REACTIVATE, CANCEL en de 


varianten hierop geldt dat deze betrekking hebben op het aangegeven object. 


Een object kan alleen geidentificeerd worden via een pointer die naar dit 
object verwijst. Om objecten naar zichzelf te laten verwijzen kent SIMULA de 
opdracht THIS. 

Bijvoorbeeld: 


ACTIVATE x AFTER THIS classnaam 


activeert object x meteen nadat het object waarin de betreffende ACTIVATE 
is opgenomen passief geworden is. Voor de volledigheid: 
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ACTIVATE x AFTER current 


heeft hetzelfde effect. 
De pomp(bediende) van het tankstation in voorbeeld 2.1 kan nu als volgt 
worden gedeclareerd als een PROCESS-class in SIMULA: 


Voorbeeld 6.6: De procesbeschrijving van ‘pompbediende’ in SIMULA 


PROCESS CLASS pompbediende; 
BEGIN REF (auto) klant; 
WHILE TRUE DO 
BEGIN IF wachtrij.EMPTY THEN PASSIVATE; 
klant :- wachtrij.FIRST; 


klant .OUT; 
HOLD (klant .bedieningstijd) ; 


In het besturingsprogramma komen de volgende declaraties en statements voor: 


REF(HEAD) wachtrij; 

REF (pompbediende) bediende; 
wachtrij :- NEW HEAD; 
bediende :- NEW pompbediende; 


Toelichting: 

Na de creatie van de bediende, als object van PROCESS CLASS pompbe- 
diende, zal deze beginnen met de status passief aan te nemen. Na activering 
zal hij telkens de eerste auto uit de wachtrij nemen en verdere acties uitstellen 
tot na de bedieningstijd van de betreffende klant. Als hij merkt dat de wachtrij 
leeg is, wordt hij passief. Om hem uit die eventuele passiviteit te wekken zal een 
auto die als eerste in de rij plaats neemt, de opdracht ‘ACTIVATE bediende’ 
moeten geven (in voorbeeld 6.5. is hierin nog niet voorzien, maar in voorbeeld 
6.12, aan het einde van dit hoofdstuk wel). 


Binnen SIMULA is ook het besturingsprogramma (Zie procesbeschrijving 
BESTURING van figuur 2.14) een PROCESS-object (onder de naam MAIN). 
Hierdoor is het mogelijk de duur van de simulatie vast te leggen in het bestu- 
ringsprogramma. 


Dit kan op twee manieren: 


a. De totale tijdsduur die men wil simuleren is vooraf bekend. Het be- 
sturingsprogramma MAIN kan dan worden opgeschort met behulp van 
HOLD(simulatieduur), zie voorbeeld 6.12. 

b. De totale tijdsduur die men wil simuleren is niet vooraf bekend maar 
hangt af van een of andere voorwaarde (bijvoorbeeld 2000 orders ver- 
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werkt in een job-shop). Dan moet het besturingsprogramma MAIN pas- 
sief worden gemaakt (opschorten voor onbepaalde tijd) met behulp van 
een PASSIVATE in het besturingsprogramma. Op het moment dat aan 
de betreffende voorwaarde voldaan is moet vanuit het object waar dat 


wordt geconstateerd het besturingsprogramma worden geactiveerd door 
middel van ACTIVATE MAIN. 


6.5 Taalkundige aspecten van SIMULA 


In deze paragraaf zal een overzicht van enkele belangrijke taalelementen ge- 
geven worden. Achtereenvolgens zullen behandeld worden: sleutelwoorden, de- 
claraties, expressies, statements en de scope van variabelen. 


615.1 Sleutelwoorden 


Binnen SIMULA mogen de hierna opgesomde woorden niet als variabele-, 
functie-, procedure- of classnaam gebruikt worden. 


ACTIVATE ELSE IS REAL 
AFTER END LABEL REF 
AND EQV NAME STEP 
ARRAY FALSE NEW SWITCH 
AT FOR NONE TEXT 
BEFORE GOTO NOTEXT THEN 
BEGIN IF OR THIS 
BOOLEAN IMP OTHERWISE TRUE 
CHARACTER IN PRIOR UNTIL 
CLASS INNER, PROCEDURE VALUE 
COMMENT INSPECT QUA VIRTUAL 
DELAY INTEGER REACTIVATE WHEN 
DO WHILE 
NOT 


6.5.2 Declaraties 


Alle variabelen, functies, procedures en classes, die in een programma wor- 
den gebruikt, moeten van te voren worden gedeclareerd. De volgende typen 
declaraties zijn van belang: 


e INTEGER, : Variabelen van dit type kunnen alleen gehele getallen als 
waarde bevatten. Na declaratie hebben ze initieel de waar- 
de 0. 
Declaratie: 
INTEGER varl, var2, ..., varn; 
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e REAL 


e BOOLEAN 


e REFERENCE 


e CHARACTER 


e ARRAY 
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: Variabelen van dit type kunnen tot een bepaalde nauw- 


keurigheid reéle getallen bevatten. Na declaratie hebben 
deze initieel de waarde 0.0. 

Declaratie: 

REAL varl, var2, ..., varni 


: Boolean variabelen kunnen als waarde TRUE of FALSE 


hebben. Na declaratie hebben Boolean variabelen initieel 
de waarde FALSE. 

Declaratie: 

BOOLEAN varl, var2, ..., varj; 


: Reference variabelen (pointers) kunnen als waarde NONE 


of een verwijzing naar een object bevatten. NONE bete- 
kent dat de betreffende pointer geen object aanwijst. Het 
object dat door een pointer wordt aangewezen moet van 
het zelfde type zijn als opgegeven bij de declaratie. Initieel 
hebben pointers na declaratie de waarde NONE. 
Declaratie: 

REF (classnaam) pointerl, pointer2, ..., pointeru; 


: Charactervariabelen kunnen als waarde een willekeurig 


symbool (letter, cijfer etc.) bevatten. Na declaratie be- 
vatten ze initieel een onbekende waarde. 
Declaratie: 


CHARACTER varl, var2, ..., varm; 


: Van de bovenstaande typen variabelen kunnen array’s ge- 


vormd worden. De declaratie van één-dimensionale array’s 
is als volgt: (Voor meer-dimensionale arrays zie de AL- 
GOL literatuur) 

Declaratie: 

Type ARRAY arrl, arr2, ..., arrn(AE1:AE2); 


waarbij type staat voor INTEGER, REAL, BOOLEAN, 
REF(classnaam) of CHARACTER. 

AE1 en AE2 zijn aritmetische expressies van het type IN- 
TEGER die de beneden- en bovengrens voor de array in- 
dex aangeven. De betreffende expressies moeten op het 
moment van declaratie een toegestane waarde opleveren: 


AE2 > = AE. 


e PROCEDURES EN FUNCTIES: 


Declaratie van een functie: 
Type PROCEDURE procedurenaam(parameterlijst); de- 
claratie parameterlijst; BS; 


of 
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Type PROCEDURE procedurenaam; BS; 


waarbij BS staat voor Blockstatement (zie 6.5.4). Indien 
‘type’ wordt weggelaten spreken we van een procedure en 
kan de procedurenaam in het aanroepende programma als 
statement worden opgenomen. 

Wordt bijvoorbeeld ‘type’ niet weggelaten dan levert de 
aanroep van de functieprocedure een waarde op welke toe- 
gekend wordt aan de procedurenaam en spreken we van 
een functie. Type geeft aan van welk type de door de func- 
tie berekende en aan de functienaam toegekende waarde 
is. 

Type moet net als bij array’s van het soort INTEGER, 
REAL, BOOLEAN, REF(classnaam) of CHARACTER 
zijn. Wordt in de functiebody BS geen waarde toegekend 
aan de functienaam dan levert de procedurenaam bij aan- 
roep de voor het betreffende ‘type’ initiéle waarde op. Een 
functienaam moet bij aanroep in het programma altijd 
rechts van het assignment-teken (:= of :—) in een expres- 
sie voorkomen. 


e CLASS : De declaratie van een class lijkt sterk op die van een pro- 
cedure. 
Declaratie: 
Prefixclassnaam CLASS classnaam (parameterlijst); de- 
claratie parameterlijst; BS; 


of 
Prefixclassnaam CLASS classnaam; BS; 


Indien ‘prefixclassnaam’ wordt ingevuld dan is de class 
‘classnaam’ een subclass. Wordt er geen ‘prefixclassnaam’ 
opgegeven dan is ‘classnaam’ een ‘zelfstandige’ class. De 
‘prefixclassnaam’ moet de naam van een andere class zijn 
die ofwel in hetzelfde programmablok of in een program- 
mablok dat dit omvat gedeclareerd is, ofwel gedeclareerd 
is in de prefix van het gehele programma. Bijvoorbeeld 
‘PROCESS’ mag als ‘prefixclassnaam’ gebruikt worden 
als het programma ‘geprefixed’ is met ‘SIMULATION’ 
aangezien ‘PROCESS’ als class gedeclareerd is in de sy- 
steemclass ‘SIMULATION’. 


De bovenstaande typedeclaraties mogen elkaar in willekeurige volgorde 
opvolgen. Men hoeft dus bijvoorbeeld niet eerst alle integer variabelen te de- 
clareren, daarna alle real variabelen etc. 
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6.5.3 Expressies 


Binnen SIMULA bestaan vier soorten expressies: aritmetische (rekenkundige), 
character-, object- (pointer) en boolean expressies; en twee soorten toeken- 
ningstekens :— voor objectexpressies en := voor alle andere expressies. Het 
geheel aan expressies in SIMULA is veel uitgebreider dan hieronder behan- 
deld. Een volledig overzicht valt buiten de opzet van dit boek. Zie hiervoor 
Birtwistle. 


e Aritmetische expressies (AE): 


Aritmetische expressies kan men opbouwen m.b.v. variabelen, arrayele- 
menten en functies van het type INTEGER of REAL en de volgende 
operaties: 


+ optelling 

— aftrekking of negatie 

/ deling (real) 

x  vermenigvuldiging 

// gehele deling (restterm vervalt) 
xx machtverheffen 


Het toekenningsteken is := . 
Binnen SIMULA zijn standaard onder andere de volgende functies be- 
schikbaar. (Dit betreft reéelwaardige functies, uitgezonderd de laatste 


twee): 
ABS(x) absolute waarden van x 
ARCTAN(x) arctangens van x 
COS(x) cosinus van x 
SIN (x) sinus van x 
TAN(x) tangens van x 
EXP(x) e-macht van x 
LN(x) natuurlijke logaritme van x 
SQRT(x) vierkantswortel van x 
SIGN(x) teken van x: —1,0 of 1 


EN Tier(x) dichtsbijzijnde integerwaarde 
kleiner of gelijk aan x 


Bij het aanroepen van functies moet men hun eventueel gedeclareerde 
parameters van een waarde van het juiste type voorzien. 
Bijvoorbeeld: 


hoogte := 2 * COS(hoek/2). 
Waarbij hoogte en hoek variabelen van het type REAL zijn. 
e Characterexpressies (CE) 


Characterexpressies leveren als waarde een karakter. 
Het toekenningsteken voor een characterexpressie is := waarbij het ka- 
rakter tussen quotes staat. 
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Klasse := ‘N’. 


Alle functies die CHARACTER als ‘type’ hebben zijn in character ex- 
pressies toelaatbaar. 


e Objectexpressies (OE) 


Een object expressie levert als resultaat een object op. Mogelijke object- 
expressies zijn: 


NONE geen object toegekend 

NEW classnaam; indien geen parameters nodig 

NEW classnaam(parameterwaarden); 
indien parameters aanwezig. Deze parameterwaarden 
kunnen ook weer via expressies worden verkregen. 

THIS classnaam; levert verwijzing naar current object op. 

p pointer naar een object 

Het toekenningsteken is :— . 


Bijvoorbeeld: 
p:-NEWA 


Rechts van het :- teken zijn alle gedefinieerde functies toegelaten die als 
type REF(classnaam) hebben, evenals alle functies die in pararagraaf 
6.4 voor LINK en PROCESS objecten zijn gedefinieerd. Men moet erop 
letten dat het objecttype (classnaam) dat een objectexpressie oplevert 
van dezelfde soort is als de variabele waaraan de waarde wordt toegekend. 
Uitzondering hierop is ‘NONE’ dat voor alle objecttypen voldoet. 


met A een classnaam 


e Boolean expressie (BE) 


Boolean expressies leveren als waarde TRUE of FALSE op en kunnen 
m.b.v. de boolean operatoren uit onderstaand overzicht geconstrueerd 


worden. 
Overzicht verschillende boolean operatoren: 
arit. expr: AE1 < AE2 kleiner 
AE1 > AE2 groter 
AE1 <= AE2 kleiner of gelijk 
AE1 >= AE2 groter of gelijk 
AE1 = AE2 gelijk 
AE1 <> AE2 ongelijk 
object expr: OE1 == OE2 verwijzen naar zelfde object 
OE1 =/= OE2 verwijzen niet naar zelfde object 
char. expr: CE1 = CE2 karakters gelijk 
bool. expr: BEI AND BE2 en 
BE1 OR BE2 of 
NOT BEI negatie 
BEI EQU BE2 gelijk 
TRUE altijd waar 
FALSE altijd niet waar 
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B Boolean variabele 
en alle boolean gedeclareerde functies zoals 
en wachtrij. EMPTY uit 6.4.1 


Voorbeeld: 
B := ((x<=5) AND (P =/= NONE)) EQU TRUE 


N.B. Binnen alle expressies kan men d.m.v. haakjes () de gewenste volgorde 
van uitvoeren aangeven. 


6.5.4 Statements 


e Block Statement (BS) 


Een SIMULA programma als geheel bestaat uit een groot blocksta- 
tement. Een blockstatement (BS) heeft de vorm: 


BEGIN dt: d2; ...; dn; sl; s2;...; sm END 


waarbij di staat voor declaratie i (zie 6.6.2) en sj voor statement j (dit 
kan weer een blockstatement zijn). 

In SIMULA worden statements en/of declaraties onderling gescheiden 
door een puntkomma. Voor een END hoeft geen puntkomma geplaatst 
te worden. 


Compound statement (CS) 
Een compound statement is een blockstatement zonder declaraties: 
BEGIN sl; s2; ....; sk END 


Assignment statement (AS) 


Een assignment statement bestaat uit de toekenning van een expressie 
aan een variabele. 


VB := BE de boolean variabele VB wordt boolean expressie BE 

VA := AE de aritmetische variabele VA wordt aritmetische expressie AE 
VO :— OE de object variabele (pointer) VO wordt de object expressie OE 
VC := CE de character variabele VC wordt de character expressie CE 


Binnen SIMULA zijn ook meervoudige toekenningen mogelijk. 
Bijvoorbeeld: 


A := B := C := expressie 
met als effect 


C := expressie; B := C; A := B. 
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e IF statement (IS) 


Het IF statement komt in twee vormen voor: 


1. IF BE THEN S1 BE: boolean expressie 
S1 : statement 


Dit kan als volgt schematisch voorgesteld worden in de vorm van 
een stroomdiagram: 


false true 


2. IF BE THEN S1 ELSE S2 BE: boolean expressie 
S1 : statement 
S2 : statement 


in stroomdiagramvorm: 


Er dient op gelet te worden dat er tussen S1 en ‘ELSE’ nooit een punt- 
komma mag staan. (Dan wordt ELSE nl. opgevat als het begin van een 
nieuw, onbekend statement!) 


S1 mag niet uit een conditioneel statement bestaan, dus niet alleen IS, 
WS, of FS. 
Bijvoorbeeld: 


IF BEI THEN IF BE2 THEN … 
is binnen SIMULA niet toegestaan. 
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e WHILE statement (WS) 


Het WHILE statement dient voor implementatie van programmaloops 
en heeft de volgende vorm: 


WHILE BE DOS BE: boolean expressie 


S: statement 


false 


e FOR statement (FS) 


Het FOR statement dient voor het een vast aantal malen uitvoeren van 
een statement, en heeft de vorm: 


FOR VA := AE1 STEP AE2 UNTIL AE3 DOS 


met VA: aritmetische variabele 
AE1, AE2, AE3 aritmetische expressies 
S: statement 


VA := 
VA+AEZ 
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LINKAGE 


LINK 


EVTIME 1 
LINK-body 


LINKAGE 


LINK ‘losstaand’ 


PROCESS- 
PROCESS EVTIME 1 object 


PROCESS-body 


gebruikers- 
j EVTIME 3 


Figuur 6.6: De relaties tussen de eventketting en PROCESS-objecten, die 
tevens deel uit kunnen maken van gebruikerskettingen 


Om de werking van een aantal standaardprocedures m.b.t. PROCESS- 
objecten toe te lichten zullen we in plaats van figuur 6.6 de meer symbolische 
figuur 6.7 gebruiken waarin de PROCESS-bodies centraal staan. Hierin wordt 
het klokmechanisme binnen SIMULA voorgesteld als een ketting met ‘haken’ 
(= de eventketting). 
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systeemtijd 
mn Be 


A: initiële situatie 3 5 eventketting 


actief suspended passief 


systeemtijd 
e 


B: effect van HOLD(6) ? eventketting 


op situatie A 


systeemtijd 
— 


C: effect van 5 7 eventkett ing 


PASSIVATE op 
situatie A 


actief \_ suspended passief 


systeemtijd 
nnn 


D: effect van 11 eventkett ing 


ACTIVATE E op 
situatie A 


actief suspended 


Figuur 6.7: Quasi-parallelle processen in SIMULA m.b.v. een eventketting. 
Het gearceerde gedeelte van het actieve object geeft de positie aan van het 
statement waarmee de executie van de body van een component (her)start. 
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e Procedurestatement (PS) 


Men mag alle standaard- en zelf gedefinieerde procedures als statement 
aanroepen, waarbij men wel de parameters, indien aanwezig, van waarden 
moet voorzien met behulp van expressies. Dus 


procedurenaam(EL) 


indien parameters aanwezig 
EL: expressielijst voor parameters 


of 
procedurenaam 


indien geen parameters aanwezig 


Voorbeeld: 
OUTINT(A,b) 


is de aanroep van de standaardprocedure voor het afdrukken van een 
variabele A van het type INTEGER waarvoor b posities gebruikt worden. 


e COMMENT statement 


Een COMMENT statement dient voor het toevoegen van tekst aan een 
programma welke door de compiler wordt genegeerd. 
Het heeft de volgende vorm: 


COMMENT commentaar ...: 


WA 


Het einde van het commentaar wordt aangegeven door de eerstvolgende 
puntkomma. Tevens geldt dat alles wat na een END komt tot aan de 
eerstvolgende END of puntkomma ook als commentaar opgevat wordt. 
Bijvoorbeeld: 


BEGIN BEGIN S END commentaar END 
BEGIN S; BEGIN S END commentaar; S END 


6.5.5 Het bereik (geldigheidsgebied) van variabelen 


Iedere gedeclareerde variabele in SIMULA is gedefinieerd en dus bereikbaar 
zolang het blok waarin deze gedeclareerd is, in uitvoering is. Dus in het pro- 
gramma segment (blok) 


BEGIN INTEGER K; BEGIN INTEGER I; S1 END; S2 END 


kunnen de variabelen K en I beide in statement S1 gebruikt worden terwijl 
in statement S2 dit alleen voor variabele K geldt. Een uitzondering op deze 
regel vormen de locale declaraties in een class object. Deze blijven gedefinieerd 
zolang er een pointer naar het betreffende object verwijst. Locale variabelen 
in een object zijn van buiten dat object bereikbaar via de puntnotatie. 
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Binnen SIMULA zijn variabelen hiérarchisch gerangschikt, waarbij men 
dieper in de hiérarchie gaat naarmate meer blocks openstaan bij de declaratie. 
Een block staat open wanneer van dit block wel de BEGIN is geweest maar 
niet de END. Bijvoorbeeld: 


ole a a ee 


q 2 1 2 3 2 1 hiérarchisch 
niveau 


Bij aanroep van een variabele wordt vanaf het niveau van de aanroep naar 
boven toe alle niveau’s doorzocht naar de eerste declaratie van een variabele 
met deze naam. Wordt geen declaratie gevonden dan resulteert dit in een 
foutmelding. 

Wordt wel een declaratie gevonden dan wordt de huidige waarde van die 
betreffende variabele genomen. Dit heeft dus tot gevolg dat van hiërarchisch 
dubbel gedeclareerde variabelen slechts die van het diepste niveau bereikbaar 
is. 

Ter illustratie: 


integer X, Y, Z; niveau 1 
Ki 4 ` 


niveau 2 
c= 2 


integer X; 
X :=3 niveau 3 
(X=3, Y=2, Z=1) 


(X=2, Y=2, Z=1) 


Tussen haakjes staan de waarden van 
de variabelen op dat niveau 


BEGIN INTEGER X, Y, Z; X := 
BEGIN INTEGER X, Y; X : 
BEGIN INTEGER X 
END 
END 
END 


Vermijd zoveel als mogelijk het declareren van variabelen met dezelfde naam! 
Voor procedures, functies en classes geldt dat de binnen deze gedeclareerde 
variabelen ‘voorrang hebben’ op de erbuiten gedefinieerde variabelen. 
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Bij gebruik van de puntnotatie voor classobjecten wordt niet meer hiérar- 
chisch gezocht. Komt de gevraagde variabele niet voor in net object record dan 
volgt er een foutmelding. 


6. 5. 6 Standaard procedures en functies ten behoeve van 
in- en uitvoer 


De volgende standaard input functies zijn beschikbaar: 


ININT getal zonder decimale punt, bijv. 12 
INREAL getal met decimale punt, bijv. 12.3 


Deze functies leveren bij aanroep de waarde van het ingelezen getal. 
Bijvoorbeeld: 


I:=ININT; 
SIMULA kent de volgende standaard output procedures: 


OUTIMAGE op een nieuwe regel verder gaan 

OUTINT(AE,n) uitprinten integer variabele AE waarbij 
n posities gebruikt worden 

OUTFIX(AE,M,W) uitprinten real variabele waarbij W posities 
gebruikt worden (waarvan 1 positie wordt 
gebruikt voor het afdrukken van de decimale 
punt) met M symbolen achter de decimale punt 

OUTCHAR(CE) uitprinten een karakter 

OUTTEXT” tekst”) uitprinten tekst 


6.6 Statistische functies 


Binnen SIMULA zijn standaard functies beschikbaar om trekkingen uit ver- 
schillende verdelingen te genereren. 

Bij de implementatie van deze functies wordt gebruik gemaakt van een 
random generator. 

Een random generator kan worden voorgesteld als een procedure f die uit- 
gaande van een integer getal een ander ‘willekeurig’ integer getal berekent. Een 
serie random getallen krijgt men dan als volgt: 


UO startwaarde 
U1=f(UO) le getal 
U2=f(U1) 2e getal 
Un=f(Un-1) ne getal 


Uitgaande van een gegeven startwaarde levert de random generator steeds 
dezelfde serie random getallen. Hierdoor is het mogelijk om het gedrag van 
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modellen onder verschillende condities (bijvoorbeeld verschillende parameter- 
waarden van het model) te vergelijken, waarbij verschil in modeluitkomsten 
niet wordt veroorzaakt door andere trekkingen uit een bepaalde verdeling. 
Voor het reproduceerbaar genereren van een serie random getallen bevatten 
de standaard statistische functies de parameter U. Deze parameter U dient 
enerzijds als invoergetal voor de randomgenerator, anderzijds als opslagplaats 
voor het nieuw berekende ‘random’ getal. Binnen SIMULA wordt het type van 
een parameter die zowel voor invoer als voor uitvoer dient, gedeclareerd met 
behulp van NAME. Daarnaast moet ook nog apart gedeclareerd worden tot 
welk type U behoort. Door een andere startwaarde voor U te kiezen (waarbij 
U niet negatief mag zijn) kan men een andere reeks random getallen en zo dus 
trekkingen genereren. 


Hieronder volgen enkele veel gebruikte standaard beschikbare statistische func- 
ties. 


1. BOOLEAN PROCEDURE DRAW (A,U); NAME U; REAL A; INTEGER U; 
levert indien: 


Ot A eee : de waarde TRUE met kans A, de waarde FALSE 


met kans 1-A. 
A <0 : de waarde FALSE 
A> I : de waarde TRUE 


2. INTEGER PROCEDURE RANDINT(A,B,U); NAME U; INTEGER A,B,U; 
levert indien: 


A= B : met gelijke kans één van de waarden A, A+1,..., 
B-1, B. 
A >B : een foutmelding. 


3. REAL PROCEDURE NEGEXP(A,U); NAME U; REAL A; INTEGER U; 
levert indien: 


A> 0 : een trekking uit een negatief exponentiële verdeling 
met gemiddelde 1/A (dus met intensiteit A). 
As 0 : een foutmelding. 


4. INTEGER PROCEDURE POISSON(A,U); NAME U; REAL A; INTEGER U; 
levert indien: 


Apel : een trekking uit een Poissonverdeling met parameter 
A. 
A <0 : de waarde nul. 


5. REAL PROCEDURE ERLANG(A,B,U); NAME U; REAL A,B; INTEGER U; 
levert indien: 


A>0OenB>0 : een trekking uit een Erlangverdeling met gemiddelde 
1/A en standaard deviatie 1/(A * B). 
A <= 0 of B <= 0: een foutmelding. 
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6. REAL PROCEDURE UNIFORM(A,B,U); NAME U; REAL A,B; INTEGER U; 


levert indien: 


A < B : een trekking x uit een uniforme verdeling in het be- 
rek A =< x: <-B. 
A>=B : een foutmelding. 


. REAL PROCEDURE NORMAL(A,B,U); NAME U; REAL A,B; INTEGER U; 


levert indien: 


B >= 0.0 : een trekking uit een normale verdeling met gemid- 
delde A en standaard deviatie B. 
B < 0.0 : een foutmelding. 


6.7 De implementatie van een procesbeschrij- 


ving voor het tankstation 


Uitgangspunt hierbij is figuur 2.14. Hieronder volgen per componentklasse de 
bijbehorende attributen en procesbeschrijving (activiteitenlijst). 


1 
hak 


1:2 


2.2 


Componentklasse aankomstgenerator 

Attributen 

gemtat (gemiddelde tussenaankomsttijd) 

Activiteitenlijst: 

WHILE TRUE 

DO bepaal aankomsttijdstip volgende auto; 
wacht tot aankomsttijdstip volgende auto; 
creëer en activeer nieuwe auto; 
laat waarnemer aantal aangekomen auto’s 
naankomst, aanpassen. 


OD; 


Componentklasse auto 
Attributen. 
aankomsttijd, bedieningstijd, 
Activiteitenlijst: 
noteer aankomsttijd, bepaal bedieningstijd, 
IF rijlengte < maxrijl 
THEN ga in wachtrij 
IF bediende (pomp) = vrij THEN activeer bediende 
ELSE rij door; 
laat waarnemer aantal doorgereden auto’s, 
ndoorrijder, aanpassen; 


Componentklasse pompbediende. 
Attributen: 

vrij (het vrij zijn van de pompbediende), 
klant (referentie naar de te bedienen auto) 
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3.2 Activiteitenlijst: 
WHILE TRUE 
DO IF wachtrij leeg THEN wacht op aankomst auto 
in wachtrij; neem eerste auto uit wachtrij; 
laat waarnemer wachttijd auto noteren (somwt); 
wacht tot einde bedieningstijd; 
auto vertrekt; laat waarnemer aantal bediende auto’s, 


nbediend, aanpassen; 
OD; 


4. Componentklasse rapportage(waarnemer) 
4.1 Attributen: 
naankomst, ndoorrijder, nbediend, somwt, somkwt 
4.2 Activiteitenlijst: 
Diverse waarneemprocedures om de gewenste metingen 
uit te kunnen voeren; 
Initialisatieprocedure attribuutwaarden; 


Voor het kunnen uitvoeren van de simulatie zijn de volgende componenten 
nodig: 
e 1 aankomstgenerator van de componentklasse aankomstgenerator, 


e een nog onbekend aantal auto’s van de componentklasse auto (er zal een 
dag van 24 uur gesimuleerd worden) 


e 1 bediende van de componentklasse pomp(bediende), 
e 1 waarnemer van de componentklasse rapportage 


e 1 wachtrij van de systeemklasse HEAD. 
Het simulatieproces verloopt globaal als volgt: 


e initialisatie (creatie/activatie diverse componenten) 


e wachten tot de tijd nodig voor het simuleren van 1 werkdag van 24 uur 
voorbij is (aangegeven door middel van het rondje in de procesbeschrij- 
ving van de besturing in figuur 2.14) 


e rapportage van de gewenste output. 


Uitgaande van het bovenstaande komen we tot de volgende implementatie van 
het tankstation van voorbeeld 2.1 in SIMULA. 
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Voorbeeld 6.12: Het SIMULA programma voor het tankstation 


BEGIN COMMENT tankstation; 
SIMULATION 
BEGIN COMMENT Hieronder volgen alle declaraties; 


REAL gemtat, og, bg; 
INTEGER simulduur ,maxrijl,startw; 


PROCESS CLASS generator(gemtat);REAL gemtat; 
BEGIN WHILE TRUE DO ~ 
BEGIN HOLD(NEGEXP(1/gemtat, startw)); 
NEW auto; 
waarnemer.aankomst 
END 
END***generator***; 


LINK CLASS auto; 
BEGIN REAL aankomsttijd, bedieningstijd; 
REAL PROCEDURE wachttijd; 

BEGIN wachttijd:=Time-aankomsttijd END; 
aankomsttijd:=Time; 
bedieningstijd:=UNIFORM(og, bg, startw); 

IF wachtrij.CARDINAL<maxrijl THEN 
BEGIN INTO(wachtrij); 
IF bediende.vrij THEN ACTIVATE bediende 
END 
ELSE 
waarnemer .doorrijder; 
END*¥**auto*¥**; 


PROCESS CLASS pompbediende; 
BEGIN REF(auto) klant; 
BOOLEAN vrij; 
vrij :=TRUE; 
WHILE TRUE DO 
BEGIN IF wachtrij.EMPTY THEN PASSIVATE; 
klant :- wachtrij.FIRST; 
klant . OUT; 
vrij:=FALSE; 
waarnemer.noteerwt (klant.wachttijd) ; 
HOLD(klant.bedieningstijd) ; 
waarnemer. bediend; 
vrij:=TRUE 
END 
END***pompbediende***; 


CLASS rapportage; 
BEGIN INTEGER naankomst ,ndoorrijder ,nbediend; 
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REAL somwt,somkwt; 
PROCEDURE aankomst ; 

BEGIN naankomst:=naankomst+1 END; 
PROCEDURE doorrijder; 

BEGIN ndoorrijder:=ndoorrijdert+i END; 
PROCEDURE noteer(wt);REAL wt; 

BEGIN somwt:=somwttwt ; 

somkwt:=somkwttwt*wt ; 

END; 

PROCEDURE bediend; 
BEGIN nbediend:=nbediend +1 END; 
REAL PROCEDURE spreiding; 

BEGIN IF nbediend>1 THEN 
spreiding:=SQRT((somkwt- 
somwt*somwt/nbediend) /(nbediend-1) ) 

ELSE spreiding:=-1 

END; 

PROCEDURE report; 
BEGIN OUTIMAGE; 


OUTTEXT ("aantal aankomsten aad E 
OUTINT (naankomst ,6) ; OUT IMAGE ; 

OUTTEXT ("aantal doorrijders nyo 
OUTINT (ndoorrijder ,6) ;OUTIMAGE; 

OUTTEXT ("aantal auto’s bediend gt) s 
OUTINT (nbediend, 6) ;OUTIMAGE; 

OUTTEXT ("percentage doorrijders aM") 


OUTFIX(100*ndoorrijder/naankomst ,2,7) ; 
OUTTEXT (''%") ; OUT IMAGE ; OUTIMAGE; 
OUTTEXT ("gemiddelde wachttijd Jos E 
IF waarnemer.nbediend>0 THEN 
OUTFIX(somwt/nbediend,2,7) 
ELSE OTTEXT ("GEEN BETEKENIS"); 
OUTIMAGE; 
OUTTEXT ("spreiding “Set A 
OUTFIX(spreiding ,2,7) ;OUTIMAGE 

END; 


naankomst :=ndoorrijder:=nbediend:=0; 
somwt :=somkwt :=0.0; 
END***rapportage***; 


PROCEDURE initialiseer; 

BEGIN gemtat:=4;0g:=2; bg: =5; 
startw:=1785392;simulduur:=24*60;maxrijl:=3; 
waarnemer :- NEW rapportage; 
bediende :- NEW pompbediende; 
wachtrij :- NEW HEAD; 
gen :- NEW generator(gemtat) 

END; 
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REF (pompbediende) bediende; 
REF (rapportage) waarnemer; 
REF(HEAD) wachtrij; 
REF (generator) gen; 


COMMENT Hieronder volgt het hoofdprogramma MAIN; 


BEGIN initialiseer; 
ACTIVATE bediende; 
ACTIVATE gen; 
HOLD (simulduur); 
waarnemer .report; 
OUTIMAGE 

END 

END 
END 


@execute pomp.sim 
SIMULA: POMP 

LINK: Loading 

[LNKXCT POMP execution] 


aantal aankomsten : 347 
aantal doorrijders : 24 
aantal auto’s bediend 4 322 
percentage doorrijders 26.924 
gemiddelde wachttijd HE 
spreiding a l Soak 


2 garbage collection(s) in 79 ms 


End of SIMULA program execution. 
CPU time: 3.01 Elapsed time: 5.63 


Opmerking: 

Zoals reeds opgemerkt in hoofdstuk 2 kan eenzelfde systeem op geheel verschil- 
lende wijzen met een procesbeschrijving worden weergegeven. Dit hangt er met 
name vanaf of men het systeem meer vanuit de tijdelijke componenten (klant, 
produkt) of meer vanuit de vaste componenten (bediende, machine, wachtrij) 
beschouwt. In het eerste geval ontstaat een uitgebreide beschrijving van de 
tijdelijke component, waarin als het ware zijn hele gang door het systeem be- 
schreven wordt. De beschrijvingen van de vaste componenten blijven heel kort: 
het enige wat voor deze van belang is, is of zij bezet of vrij zijn (klant is slim, 
bediende dom). In het andere geval wordt van elke vaste component volledig 
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beschreven wat er gebeurt als een tijdelijke component passeert. De beschrij- 
ving van de tijdelijke component wordt dan heel beperkt: het enige wat nog 
van belang is, is zijn ‘capaciteitsbehoefte’ (klant is dom, bediende slim). 

Bij implementatie in SIMULA blijkt in de praktijk dat deze laatse opvatting 
veelal tot de eenvoudigste programma’s leidt. 


6.8 Opgaven 


1 De eigenaresse van het tankstation van voorbeeld 2.1 vraagt zich af of 
het de moeite zou lonen een smeerplaats te openen en hiervoor parttime 
iemand in dienst te nemen. 

Verder zou ze de wachtruimte voor zowel de pomp als de smeerplaats 
‘oneindig’ groot willen maken. 

Uit een enquete onder haar klanten weet ze dat van elke 10 auto’s er 
gemiddeld 7 alleen bezine nodig hebben en 3 tevens hun auto zouden 
willen laten smeren. 

Ze wil nu weten: 


— het aantal auto’s dat dan per dag zou komen tanken: 
— de gemiddelde doorlooptijd met betrekking tot tanken voor 1 auto; 
— het aantal auto’s dat dan per dag gesmeerd zou worden; 


— de gemiddelde doorlooptijd met betrekking tot het smeren van 1 
auto. 


Een adviesburo/student heeft in dat kader het onderstaande simulatie- 
programma gemaakt. 
Verifieer de juistheid van dit programma. o 


BEGIN 
SIMULATION 
BEGIN 
FROCESS CLASS aankgen; 
BEGIN 
WHILE TRUE DO 
BEGIN 
HOLD (NEGEXF (1/mu,ui)); 
IF DRAW(O.7,u2) THEN 
ACTIVATE NEW auto(Time) 
ELSE 
ACTIVATE NEW smeerauto(Time); 
END 
END; 


FROCESS CLASS auto(aank); REAL aank; 
BEGIN 


INTO (pomprii); 

IF pomp.vrii THEN ACTIVATE pomp AFTER CURRENT; 
PASSIVATE; 

OUT; 

HOLD (UNIFORM (a,b, frand)) 

piet.noteer (TIME-aank) ; 

ACTIVATE pomp 
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auto CLASS smeerauto; 

BEGIN 
REAL start; 
start:=TIME; 
INTO (smeerri ij); 
IF smeerkees. vrij THEN 

ACTIVATE smeerkees AFTER CURRENT; 

FASSIVATE; 
OUT; 
HOLD (UNIFORM (c,d, srand)); 
pıet.smeer (TIME-start); 
ACTIVATE smeer kees; 


END; 
PROCESS CLASS bediende(rii); REF (HEAD) rijs 
BEGIN 
BOOLEAN vrij; 
vrij: =TRUE; 
WHILE TRUE DO 
BEGIN 
IF NOT rij.EMPTY THEN 
BEGIN 
ACTIVATE rij.FIRST; 
vrij: =sFALSE 
END; 
FASSIVATE; 
vrij:=TRUE 
END 
END; 
CLASS waarnemer; 
BEGIN 
PROCEDURE noteer (dltpomp); REAL dltpomp; 
BEGIN 
somdpomp: =somdpomp+dltpomp; 
npomp: =npomp+1 
END; 
PROCEDURE smeer (dltsme); REAL dltsme; 
BEGIN 
somdsme: =somdsme+dl tsme; 
nsme: =nsme+1 pe 
END; 
PROCEDURE schrijf; 
BEGIN 
OUTTEXT ("run 23 
OUT INT (i, 2) ; OUT IMAGE; 
OUTTEXT ("aantal auto’s bij de pomp "); 
OUT INT (npomp, 3) ; OUT IMAGE; 
OUTTEXT ( "gem. dlt bij de pomp eE 
OUTF I X (somdpomp/npomp, 2, 7) ; OUT IMAGE; 
OUTTEXT ("aantal auto’s bij smeren "); 
OUT INT (nsme, 3) ; OUT IMAGE; 
OUTTEXT (“gem. dlt bij smeren "TS 
OUTFIX (somdsme/nsme, 2,7) ; OUT IMAGE; 
END; 


INTEGER npomp, nsme; 
REAL somdpomp, somdsme; 
somdsme: =somdpomp: =0.0; 
nsme:=npomp: =0 

END; 


REAL mu,a,b,c,d3; INTEGER frand,srand,ul,uz, is 
REF (HEAD) pomprii,smeerri i; 

REF (bediende) pomp,smeerkees; 

REF (waarnemer) piet; 


mu: =4; :=2; b:=5; c:=4; d:= 
frand: =1254; srand:=1876; ul 
pomprij:- NEW HEAD; smeerri 
pomp:- NEW bediende(pompri i); 
smeerkees:- NEW bediende (smeerri i); 
piet:- NEW waarnemer; 


ACTIVATE pomp; 
ACTIVATE smeer kees; 
ACTIVATE NEW aankgen; 
FOR i:=1 STEP 1 UNTIL 10 DO 
BEGIN 
HOLD (8x60) ; 
piet.schrijfs 
piet:- NEW waarnemer; 
END 


END 
END 
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6 - Introductie in de taal SIMULA 


*Alhoewel SIMULA door haar object-georiénteerde opzet met name ge- 
schikt is voor de implementatie van procesbeschrijvingen, hebben we deze 
opgave opgenomen ‘ter illustratie’ van de implementatie van een event- 
beschrijving in SIMULA. 

We zullen daarbij uitgaan van de uitwerking van opgave 2 van hoofdstuk 
2. Doe dit aan de hand van de volgende stappen (overeenkomstig 7.2): 


8. a. Geef de attributen die voor de beschrijving van de verschillende 
eventklassen van belang zijn. (Houdt hierbij rekening met de ‘waar- 
nemer’). | 
b. Vervalt hier. 

c. Geef zonodig de eventbeschrijving in pseudocode. 


9. Kwantificeer het conceptueel model. 
10. Schrijf het SIMULA programma. o 


Schrijf een SIMULA programma aan de hand van de procesbeschrijving 
verkregen via de uitwerking van opgave 3 van hoofdstuk 2. Volg hierbij 
de stappen 8, 9 en 10 van werkwijze 7.2, te weten: 


8. a. Geef de attributen per componentklasse (nu inclusief die van de 
waarnemer). 
b. Geef het aantal benodigde componenten per klasse. 
c. Geef zodanig de procesbeschrijving in pseudocode. 


9. Kwantificeer het conceptueel model. 
10. Schrijf het SIMULA programma. 


Idem voor opgave 4 uit hoofdstuk 2. 
Idem voor opgave 5 uit hoofdstuk 2. 
Idem voor opgave 6 uit hoofdstuk 2. 
Idem voor opgave 7 uit hoofdstuk 2. 


*Idem voor opgave 8 uit hoofdstuk 2. 


ff) —) 0- 0o- Glg 


Idem voor opgave 9 uit hoofdstuk 2. 


Hoofdstuk 7 


Uitvoerig simulatievoorbeeld in 
SIMULA 


7.1 Inleiding 


In dit hoofdstuk wordt een wat moeilijker probleem dan dat van het tankstation 
uitgewerkt. Uitgaande van de probleemdefinitie wordt een procesbeschrijving 
gespecificeerd en vervolgens geïmplementeerd met behulp van SIMULA. 

In 7.2 zal eerst de hierbij gebruikte werkwijze, gebaseerd op figuur 1.2 en 
uitgewerkt in de daarop volgende hoofdstukken, in een 13-tal stappen worden 
opgedeeld. Vervolgens zal in 7.3 het voorbeeld volgens de gegeven werkwijze 
worden uitgewerkt. 


7.2 De werkwijze 


In figuur 1.2 is globaal aangegeven volgens welke stappen een probleem met be- 
hulp van computersimulatie kan worden opgelost. Voor de procesbeschrijving is 
de methode/techniek van uitwerken expliciet aangegeven in het volgende stap- 
penplan. Dit stappenplan geldt ook voor de event- en activiteitenbeschrijving, 
met dien verstande dat stap 6 tot en met 8 enigszins aangepast moeten worden. 
(Voor de eventbeschrijving is de aanpassing opgenomen in opgave 2.9.2). 


1. Formuleer de doelstelling van het onderzoek zo concreet als mogelijk. 
Stel hierbij de gewenste betrouwbaarheid en nauwkeurigheid van de on- 
derzoeksresultaten vast. | 


2. Bepaal de in het kader van de doelstelling relevante uitgangs-, stuur-, 
omgevings- en toestandsvariabelen. 


3. Geef een grafische weergave van het conceptueel model. 


4. Geef een analytische beschouwing van het gegeven probleem. (Zodat er 
enerzijds meer inzicht wordt verkregen in de probleemsituatie, anderzijds 
kunnen de resultaten later gebruikt worden voor een modelvalidatie). 

9. a Bepaal per componentklasse de bijbehorende ‘activiteiten’. 

b Maak hiervan een doorsnede en som alle activiteitsklassen op. 
c Geef per activiteitsklasse de bijbehorende veranderingen van de toe- 
standsvariabelen. 


6. Wijs de activiteitsklassen eenduidig toe aan de componentklassen. 
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7. Teken het stroomschema van de procesbeschrijvingen van de conponent- 
klassen (zie 2.6). 


8. a Geef de attributen per componentklasse (nu inclusief die van de 
waarnemer). 
b Geef het aantal benodigde componenten per klasse. 
c Geef zonodig de procesbeschrijving in pseudocode. 


9. Kwantificeer het conceptueel model. 
10. Schrijf het (SIMULA) programma. 


11. Bepaal de duur van de aanloopverschijnselen, het aantal benodigde sub- 
runs en de lengte ven één subrun ondermeer op basis van de resultaten 
van proefrun(s). Vergelijk de zo verkregen simulatie resultaten met die 
verkregen met behulp van de in 4 gegeven analytische beschouwing (deel 
van de validatiefase). 


12. Ontwerp een serie simulatie-experimenten en voer deze uit. 


13. Formuleer de conclusies. 


N.B. Indien de opgaven zoals weergegeven aan het eind van dit hoofdstuk in 
een onderwijsomgeving worden gebruikt, is het raadzaam dat tussen stap 
9 en 10 een tussentijdse bespreking plaatsvindt. 


7.3 Het havenprobleem 


In een haven heeft men te maken met twee typen schepen, namelijk kleine en 
grote schepen (afhankelijk van het tonnage). 

Kleine schepen komen binnen volgens een negatief exponentiële verdeling 
met een verwachte tussenaankomsttijd van 5,5 uur. 

Grote schepen komen binnen volgens een negatief exponentiële verdeling 
met een verwachte tussenaankomsttijd van 6,7 uur. 

Kleine schepen worden gelost aan kade 1 voor kleine schepen. De tijd voor 
het lossen van een klein schip is uniform verdeeld tussen 3 en 7 uur. 

Grote schepen worden gelost aan kade 2 voor grote schepen. De lostijd voor 
een groot schip is uniform verdeeld tussen 2 en 8 uur. 

Aan kade 1 kan, indien deze geheel vrij is en er geen kleine schepen in de 
haven zijn, een groot schip gelost worden. Het lossen duurt dan echter 1,5 maal 
zo lang als bij het lossen aan kade 2. Omgekeerd kan ook 1 klein schip aan kade 
2 gelost worden indien deze vrij is en er geen grote schepen in de haven zijn. 
De lostijden worden dan 2 keer zo groot als aan kade 1 het geval zou zijn. 

De queuediscipline is KBE (kortste bewerkingstijd eerst). 

De havendirectie vraagt zich af, of het niet beter zou zijn kade 1 voor grote 
schepen uit te sluiten en kade 2 voor kleine schepen uit te sluiten. Tevens zou 
de directie graag weten of de queuediscipline FIFO (first in first out) niet meer 
geëigend is voor haar haven. 

Welk advies moet aan de havendirectie worden gegeven? 
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Uitwerking 


Stap 1: Doelstelling van het onderzoek 


Uit de gegeven probleemstelling leiden we de volgende doelstelling af: Bepaal 
het verschil tussen de verwachte gemiddelde doorlooptijden van de schepen 
voor de twee situaties voor de twee queuedisciplines (zowel voor de grote als 
de kleine schepen) met een betrouwbaarheid van 95% en een onnauwkeurigheid 
van 10%. 


Stap 2: Variabelen 


Uit de doelstelling volgt dat de gemiddelde doorlooptijden bepaald moeten 
worden. Dit zijn dus uitgangsvariabelen die door de ‘waarnemer’ aangeleverd 
moeten worden waartoe deze registraties in het gesimuleerde systeem moet ver- 
richtten (zie figuur 2.3). Tevens hebben we te maken met de uitgangsvariabele 
van het reéle systeem, te weten: vetrekkende schepen. 

Uit de probleemstelling volgt dat we te maken hebben met 2 stuurvariabelen 
namelijk de kade toewijzingsstrategie en de queuediscipline. 

De omgeving komt tot uiting in de variabelen: tussenaankomsttijd, bedie- 
ningstijd en soort schip. | 

De toestandsvariabelen zijn in dit geval: het PER wachtende schepen van 
elke soort en het al dan niet vrij zijn van kade 1 en kade 2. 


a 


Stap 3: Conceptueel model 


Het conceptueel model wordt vastgelegd op de wijze zoals aangegeven in 2.3. 
Dat wil zeggen dat achtereenvolgens 


e de systeemgrens, 

e de vaste componentklassen, 

e de tijdelijke componentklassen en 

e de relaties tussen de componenten moeten worden vastgesteld. 


De systeemgrens is in dit voorbeeld duidelijk. 


De vaste componentklassen zijn: 


e kade (1 klasse, 2 componenten: kade 1 en kade 2), 
e wachtrij. 


De tijdelijke componentklasse is: 


e schip (1 klasse, waarbinnen onderscheid gemaakt wordt tussen kleine en 
grote schepen). 


In onderstaande figuur worden de systeemgrens en de relaties tussen de com- 
ponenten weergegeven. 
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vertrek 
1 


systeemgrens 


Figuur 7.1 Grafische weergave van het conceptueel model van de haven 


Stap 4: Analytische beschouwing 


Het doel van de analytische beschouwing is om langs analytische weg inzicht 
te krijgen in het gedrag van het systeem. Deze beschouwing zal zoveel mogelijk 
kwantitatief van aard zijn. 

Met betrekking tot het havenprobleem zullen we eerst de nieuwe situatie 
beschouwen omdat deze het eenvoudigst is. 


Kwantitatieve beschouwing nieuwe situatie. 


De kleine schepen worden alleen aan kade 1 gelost, de grote schepen alleen aan 
kade 2. 


Een probleem bij deze beschouwing is dat voor de gebruikte wachtrijdiscipline 
KBE geen analytische resultaten beschikbaar zijn. We zullen daarom eerst de 
berekeningen uitvoeren voor de eenvoudigere prioriteitsregel FIFO en vervol- 
gens hieruit de resultaten voor KBE schatten. 

Bij de nu volgende analyse wordt verondersteld dat de lezer beschikt over 
enige basiskennis op het gebied van wachtrijtheorie (Wagner 1975). 
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Kade 1 (FIFO): 
Algemeen geldt: 


E(dlt) = E(w) + E(v), waarin: 

E(dlt) = verwachtingswaarde van de doorlooptijd 
E(w) = verwachtingswaarde van de wachttijd 
E(v) = verwachtingswaarde van de bedieningstijd 


In de nieuwe situatie geldt (Pollaczek, zie Wagner 1975): 


B) Or 


mo EON dE O 2 $ 
E(v) w (1 —r) (14+ C5y), waarin 
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r = bezettingsgraad van een kade (dit is de verhouding tussen de aan- 
komstintensiteit en de maximaal mogelijke bedieningsintensiteit) 

Csv = variatiecoëfficient van de kansverdeling van de lostijden van sche- 
pen aan een kade (is gelijk aan standaarddeviatie gedeeld door 


gemiddelde). 
Voor kade 1 geldt nu: 


Cop = Sl a 0:99 
Hv 


Immers de bedieningstijd is uniform verdeeld tussen 3 en 7 zodat 


te TA a aL CE A 
cot at o a 
Voor de bezettingsgraad r van kade 1 geldt: 


Met behulp van Pollaczek vinden we dan: 


E(dlt) = E(w) + E(v) = 26,3 + 5 = 31,3 


Kade 1 (KBE): 


Volgens de wachtrijtheorie wordt het gemiddelde aantal w 


achtende klanten met 


zowel negatief exponentieel verdeelde binnenkomstintervallen als bedieningstij- 


den bij gebruik van de KBE-prioriteitsregel ongeveer gehalveerd ten ope 


van het gemiddelde aantal klanten in de wachtrij bij gebru 


| 


ik van de FIFO-regel., 


In onze benadering hebben we echter te maken met een meer deterministische 
bedieningstijd waardoor het halveringseffect niet volledig zal optreden. We 
kunnen stellen dat de doorlooptijd zal liggen tussen de bovengrens, gebaseerd 
op een deterministische bedieningstijd Csy = 0; geen halveringseffect) en de 
ondergrens, gebaseerd op een negatief exponentieel verdeelde bedieningstijd 


(Csv = 1; halveringseffect). 
De bijbehorende grenswaarden zijn: 
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18,3 < E(dit) < 31,3 


Stel.nu op basis van Csy = 0,23 dat het verkortingseffect zeer ruw geschat 
gelijk is aan: 

0,23 * 0,5 * 26,3 + 3,0. 

Dan geldt: 

E(w) = 23,3 

E(dlt) = E(w) + E(v) = 23,3 +5 = 28,3 


Kade 2 (FIFO): 


Op analoge wijze berekenen we voor kade 2: 


yee. TAD 
E(w) = 8,2 
Etait) = 13,2 


Kade 2 (KBE): 


Bij de berekening van de wachttijd met gebruikmaking van de KBE gaan we 
hetzelfde te werk als bij kade 1. Dus ruw geschat geldt: 


9,1 < E(dlt) < 13,2 
E(w) =8,2— 0,35 +0,5+8,2 = 6,8 
E(dlt) = 6,8 + 5 = 11,8 


Het op basis van de simulatieresultaten te berekenen betrouwbaarheidsinter- 
val van de gemiddelde doorlooptijd zal op zijn minst overlap moeten vertonen 
met hiervoor aangeduide interval. Een kwantitatieve beschrijving van de oor- 
spronkelijke situatie is te moeilijk. We zullen ons daarom beperken tot een 
kwalitatieve beschouwing. 


Kwalitatieve beschouwing oude situatie. 


We willen proberen vast te stellen wat het effect is van de invoering van de 
nieuwe situatie op de gemiddelde doorlooptijd van de verschillende soorten 
schepen. 

Hiertoe bepalen we achtereenvolgens de kans dat een groot schip aan kade 1 
gelost kan worden en de kans dat een klein schip aan kade 2 gelost kan worden. 


In de oorspronkelijke situatie kunnen grote schepen, indien er geen kleine 
schepen in het systeem zijn, aan kade 1 gelost worden. De kans dat er geen 
kleine schepen in het systeem zijn is: 


l-r = 0,10. 


Een groot schip kan aan kade 1 gelost worden als zich twee of meer grote 
schepen in het systeem bevinden. De kans hierop is 0,47 voor een M/D/1 
model (zie bijvoorbeeld Hillier & Yu 1981). 
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Deze kansen suggereren dat grote schepen niet vaak gelost zullen worden 
aan kade 1. Als het echter toch gebeurt, dan zal de wachtrij kleine schepen 
langer worden aangezien het grote schip het ‘loket’ bezet houdt. 

We nemen daarom aan dat de verwachte doorlooptijd van de kleine schepen 
in de oorspronkelijke situatie door het bovengenoemde effekt iets hoger zal zijn 
dan in de nieuwe situatie en die van de grote schepen iets lager. 


Kleine schepen krijgen in de oorspronkelijke situatie een kans op een ligplaats 
aan kade 2 als er geen grote schepen in het systeem aanwezig zijn. 

De kans dat er zich geen grote schepen in het systeem bevinden is gelijk 
aan 1 — 0,75 = 0,25. 

Verder moeten dan twee of meer kleine schepen in het systeem aanwezig 
zijn. Aangezien de bezettingsgraad voor kleine schepen 0.90 is, is de kans hierop 
voor een M/D/1 systeem 0,75. 


Hieruit kunnen we concluderen dat de kans dat kleine schepen gelost worden 
aan kade 2 beslist niet te verwaarlozen is. 

Indien deze situatie zich voordoet zal dit in het algemeen voor de grote 
schepen wachttijdverhogend werken. 

Voor de kleine schepen zal het wachttijdverlagend werken. 


Samenvattend kunnen we stellen dat de verwachte doorlooptijd van de grote/ 
kleine schepen in de oorspronkelijke situatie hoger /lager zal liggen dan in de 
nieuwe situatie. 


Stap 5: Activiteitsklassen 


Om tot een procesbeschrijving van het model te komen, is het nodig om de 
activiteiten van de vaste en tijdelijke componentklassen vast te stellen (zie 2.3). 

Vooruitlopend op de implementatiefase voegen we de vaste component- 
klasse ‘aankomstgenerator’ toe (zie figuur 2.14). In het reële systeem bestaat 
deze component niet, maar wordt bij de computersimulatie gebruikt om ook 
het aankomstproces na te kunnen bootsen. | 


a. De ‘activiteiten’ per componentklasse zijn: 


aank.gen. wachtrij schip 


-genereert -schip komt haven binnen 
aankomst 


-neemt schip op -gaat in wachtrij staan 
-schuift schip door -schuift door 
-verwijdert schip -gaat uit wachtrij -haalt schip 


uit wachtrij 
-plaatst schip -gaat aan kade staan -plaatst schip 
aan kade aan kade 
-schip wordt gelost -lost schip 
-verlaat het systeem -verwijdert 
het schip. 
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b. Een doorsnede van deze activiteiten leidt tot de volgende activiteitklas- 


sen: i 
A1: genereer aankomst schip 


A2: plaats schip in de wachtrij 
A31: haal schip uit de wachtrij 
A32: plaats schip aan de juiste kade 
A4: start lossen schip 
A5: haal schip van de kade en verwijder het uit het systeem 
(A6: schuif het schip door). 
De activiteitsklassen A31 en A32 treden hier altijd in combinatie op. Ze 
worden daarom verder samen aangeduid als A3. 


c. De bijbehorende veranderende toestandsvariabelen zijn: 
A2 —> rijlengte. 
A3 —> rijlengte, kade vrij. 
A5 —> kade vrij. 


Stap 6: Toewijzing activiteitsklassen 


De gevonden activiteitsklassen dienen nu eenduidig toegewezen te worden aan 
de componentklassen (zie 2.6). 
We zullen verder uitgaan van de volgende toewijzing: 


Activiteitsklassen Componentklassen 


~aankomstgenerator schip kade wachtrij 
Al x 
A2 x 


A3 
A4 
A5 
A6 


Stap 7: Het stroomschema 


In het navolgende stroomschema is de component wachtrij niet verder uitge- 
werkt omdat de activiteit ‘schuifdoor’ automatisch uitgevoerd wordt bij im- 
plementatie van een wachtrij binnen SIMULA via een lijst (vergelijk fig. 2.11, 
2.12 en 2.14). 
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BESTURING 


creëer en j creëer en 7 
activeer POETE activeer rapportage eind- 
WAARNEMER + AANKOMST rapportage 


WACHTRIJ KADEN GENERATOREN 


AANKOMST 
GENERATOR 


wacht tot 
aankomst 


A1 
CREEER EN 
ACTIVEER 
A3 nieuw schip 


UITRIJ 


A4 
START LOSSEN 


VERTREK 


activeer 


ad BESTURING 


KLAAR 


Figuur 7.2: Stroomschema haven (In dit schema is de registratie van te 
rapporteren gegevens niet expliciet aangegeven). 
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Stap 8: De procesbeschrijving in pseudo-code 
a. De attributen per componentklasse: 


De relevante attributen volgen uit de toestandsvariabelen en de overige onder 
punt 2 genoemde variabelen alsmede uit de gekozen implementatiewijze (ge- 
streefd is naar zo universeel mogelijke klassen, vandaar het attribuut ss bij de 
verschillende componentklassen). 


C1: aankomstgenerator 


attributen: ss, schipsoort 
gemtat gemiddelde tussenaankomst tijd 
og, ondergrens uniforme verdeling lostijden 
bg, bovengrens uniforme verdeling lostijden 
C2: schip 
attributen: ss, schipsoort 
ta, aankomsttijd 
tb, bedieningstijd 
C3: kade 
attributen: ss, kade primair bestemd voor schipsoort ss 
plaats, geeft aan of er plaats is aan kade ss 
C4: wachtrij 
attributen: ss, schipsoort 
nrij, rijlengte. 
C5: waarnemer 
attributen: nk, aantal vertrokken kleine schepen 
ng, aantal vertrokken grote schepen 
gdk, gemiddelde doorlooptijd kleine schepen 
gdg, gemiddelde doorlooptijd grote schepen 


In verband met het plaatsingsalgoritme van de schepen aan de kaden lijkt het 
zinvol de twee soorten schepen na aankomst gescheiden te houden. Vandaar 
twee wachtrijen, één voor grote en één voor kleine schepen. 


b. Aantal benodigde componenten: 


Cl: twee: één generator voor kleine schepen, 
één generator voor grote schepen. 

C2: moet nog bepaald worden 

C3: twee: één kade primair voor kleine schepen, 
één kade primair voor grote schepen. 

C4: twee: één wachtrij voor kleine schepen, 


C5: 


één wachtrij voor grote schepen. 


één 
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c. De procesbeschrijving in pseudocode: 


C1: aankomstgenerator(ss, gemtat, og, bg) 


WHILE TRUE 
DO trek tussenaankomsttijd; 
wacht gedurende tussenaankomsttijd; 
Al (trek bedieningstijd; 
creëer + activeer schip); 


OD; 
C2: schip(ss, ta, tb) 


A2 (plaats schip in wachtrij (ss); 
indien een kade vrij is activeer dan 
indien mogelijk kade (ss) en anders 
kade (notss)); 
wacht op A5 (vertrek van het schip uit het systeem); 
laat waarnemen doorlooptijd en vertrek van schip registreren; 
IF (nk+ng)>= subrunlengte THEN activeer MAIN; 


C3: kade(ss) 


WHILE TRUE 
DO WHILE rijlengte (ss) > 0 OR rijlengte(notss) > 0 
DO IF rijlengte (ss) > 0 
THEN A3 (haal een schip uit wachtrij(ss) en 
plaats aan kade(ss)) 
ELSE A3 (haal een schip uit wachtrij(notss) en 
plaats aan kade(ss)); 
A4 (start lossen van het schip); 
wacht gedurende bedieningstijd; 
A5 (maak kade(ss) vrij en laat schip dineke 
OD; 
wacht op A2; 
OD; 


Stap 9: Kwantificeren van het conceptuele model 


gemtat og bg 
aankomstgenerator kl. schepen 5,9 3 7 
aankomstgenerator gr. schepen 6,7 2 8 


kade voor kleine schepen 
kade voor grote schepen 
wachtrij voor kleine schepen 
wachtrij voor grote schepen 
rijdiscipline: KBE 


oa re FO ATL 


116 


7 - Uitvoerig simulatievoorbeeld in SIMULA 


Stap 10: Het SIMULA programma 


Achtereenvolgens zullen worden gepresenteerd: 


e een lijst met de betekenis van de gebruikte variabelen, 
e de source-tekst van het SIMULA programma, 
e een korte toelichting op het programma. 


AFKORTING 


dummy rij 


gdg 

gdk 
gemdlt1(k) 
gemdlt2(k) 
gemtat 

grij 

i,j,k 

krij 

lostijd 
NEGEXP 


ng 
nk 
nsa 
nsps 
nstop 
nsubr 
og 
pkss 


plaats 
qt,qn 
qth,qnh 
sdlt1 
sdlt2 
skss 


skwgemdlt1 
skwgemdlt2 
somgemdlt1 
somgemdlt2 
somkwgemdlt1 
somkwgemdlt2 


Gebruikte variabelen /functies-en hun betekenis. 


BETEKENIS 


bovengrens van de uniforme verdeling van lostijden 
doorlooptijd van een schip 

lege wachtrij (wordt gebruikt om met het hetzelfde pro- 
gramma de oude en nieuwe situatie te kunnen simuleren) 
gemiddelde doorlooptijd voor grote schepen. 
gemiddelde doorlooptijd voor kleine schepen. 
gemiddelde dlt kleine schepen voor subrun k 
gemiddelde dlt grote schepen voor subrun k 
gemiddelde tussenaankomsttijd schepen 

wachtrij voor grote schepen. 

hulptellers. 

wachtrij voor kleine schepen. 

de tijd nodig om een schip te lossen 

procedure die getallen genereert uit een negatief 
exponentiële verdeling. 

aantal vertrokken grote schepen tot nu toe 

aantal vertrokken kleine schepen tot nu toe 

aantal schepen aanlooprun 

aantal schepen per subrun. 

nsa of nsps 

aantal subruns. 

ondergrens van de uniforme verdeling van lostijden 
primaire kade (voor kleine schepen kade 1, voor grote 
schepen kade 2). 

een booleanvariabele om aan te geven of kade(ss) bezet is 
teller /noemer von Neumann ratio 

hulpvariabelen voor berekening van Neuman ratio 
hulpvariabele voor printen gemdlt1 

hulpvariabele voor printen gemdlt2 

secundaire of alternatieve kade (voor kleine schepen 
kade 2, voor grote schepen kade 1). 

variantie gemiddelde dlt1 

variantie gemiddelde dlt2 

som gemiddelde dlt1 voor alle subruns 

som gemiddelde dlt2 voor alle subruns 

som van de kwadraten van gemdlt1 voor alle subruns 
som van de kwadraten van gemdlt2 voor alle subruns 
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ss schipsoort. 

ta aankomsttijd. 

tb bedieningstijd. 

TIME systeemtijd. 

ul,u2 startwaarde voor de randomgenerator. 

UNIFORM procedure die getallen genereert uit een uniforme 
verdeling. 

wf weegfactor voor de bedieningstijd. 

wr verwijzing vanuit schip naar krij of grij. 

wrss voorrangswachtrij voor de kade (voor kade 1 krij, voor 
kade 2 grij). 

wrnotss alternatieve wachtrij voor de kade (voor kade 1 grij, 


voor kade 2 krij). 


BEGIN COMMENT havenprobleem oude situatie kbe; 
SIMULATION 
BEGIN PROCESS CLASS generator (ss,gemtat,og,bg,u1,u2); 
CHARACTER ss; REAL gemtat,og,bg; INTEGER ui,u2; 
BEGIN WHILE TRUE DO 
BEGIN COMMENT *** wacht gedurende tussenaankomsttijd 
volgende schip ***; 
HOLD (NEGEXP (1/gemtat ,u1)) ; 
COMMENT *** uitvoeren activiteit 1 ***; 
ACTIVATE NEW schip(ss,TIME,UNIFORM(og,bg,u2)) ; 
END; 
END***generator***; 


PROCESS CLASS schip(ss,ta,tb); CHARACTER ss; REAL ta,tb; 
BEGIN REF(kade) pkss,skss; REF(HEAD) wr; 

COMMENT *** uitvoeren activiteit 2: Bepaal van een 
schip zijn wachtrij, zijn primaire kade 
en Zijn secundaire kade. Zet het schip in 
zijn wachtrij en aktiveer, indien daar 
plaats is, zijn voorrangskade of anders, 
indien mogelijk, zijn alternatieve 
kade ***; 

IF ss=’k’ THEN 

BEGIN wr:-krij; pkss:-kade1; skss:-kade2 END 

ELSE | 

BEGIN wr:-grij; pkss:-kade2; skss:-kadei END; 

INTO (wr) ; 

IF pkss.plaats THEN ACTIVATE pkss 

ELSE IF skss.plaats THEN ACTIVATE skss; 

COMMENT *** wacht op activering vanuit activiteit 5 
***; 

PASSIVATE; 
COMMENT *** rapporteer het vertrek van een schip ***; 
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rap.vertrek(ss,TIME-ta) ; 
IF (rap.nk+rap.ng)>=nstop THEN ACTIVATE MAIN; 
END***schip*** ; 


PROCESS CLASS kade(ss,wrss,wrnotss,wf); 

CHARACTER ss; REF(HEAD) wrss,wrnotss; REAL wf; 

BEGIN COMMENT *** de procedure kortste bepaalt in een 
wachtrij het schip met de kortste 
bedieningstijd ***; 

REF(schip) PROCEDURE kortste(rij); REF(HEAD) rij; 
BEGIN REF(schip) boot,boot1; 
IF rij.EMPTY THEN kortste:-NONE 


ELSE 
BEGIN boot:-rij.FIRST; 
boot1:-boot ; 
WHILE boot=/=rij.LAST DO 
BEGIN boot :-boot.SUC; 
IF boot.tb<booti.tb THEN 
booti:-boot; 
END; 
END; 
kortste:-boot1; 
END; 
REF(schip) schuit; BOOLEAN plaats; REAL lostijd; 
plaats:=TRUE; 


WHILE TRUE DO 
BEGIN COMMENT *** uitvoeren activiteit 3: De kade 
probeert eerst een schip uit zijn 
primaire wachtrij te halen en te 
plaatsen. Als zijn primaire 
wachtrij leeg is probeert de 
kade een schip uit zijn secundaire 
wachtrij te halen en te 
plaatsen ***; 
WHILE wrss.CARDINAL+wrnotss.CARDINAL>=1 DO 
BEGIN IF NOT wrss.EMPTY THEN 
BEGIN schuit:-kortste(wrss); 
lostijd:=schuit.tb 
END 
ELSE 
BEGIN schuit:-kortste(wrnotss) ; 
lostijd:=schuit.tb*wf 
END; 
schuit. OUT; plaats :=FALSE; 
COMMENT *** uitvoeren activiteit 4: Wacht 
op einde bediening, d.w.z. 
totdat het schip gelost is ***; 
HOLD (lostijd) ; 
COMMENT *** uitvoeren aktiviteit 5: 
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Maak de kade vrij en 
verwijder het schip uit de 
haven ***; 

plaats:=TRUE; ACTIVATE schuit; 


END; 
PASSIVATE; 
END; 
END***Kade**+ ; 


CLASS waarnemer; 
COMMENT *** onderstaande variabelen hebben betrekking op 
subrunresultaten ***; 
BEGIN INTEGER nk,ng; 
REAL somgemdlt1i, somgemdlt2, qt, qn, qth, qnh, 
sdlti, sdlt2, 
somkwgemdlt1i, somkwgemdlt2, skwgemdlti, 
skwgemdlt2, gdk, gdg; 
REAL ARRAY gemdlti, gemdlt2 (1:100); 


PROCEDURE vertrek(ss,dlt); CHARACTER ss; REAL dlt; 
BEGIN IF ss=’k’ THEN 
BEGIN nk:=nk+1; 
sdlti:=sdlti+dlt; 
END; 
IF ss=’g’ THEN 
BEGIN ng:=ng+1; 
sdlt2:=sdlt2+dlt; 
END; 
END; 


PROCEDURE reportsubrun; 
BEGIN gdk:=sdlt1i/nk; 
gdg:=sdlt2/ng; 
OUT IMAGE ; 
OUTTEXT("subrun ") ;OUTINT(i,2); 
OUT IMAGE ; 
OUTTEXT("aantal kleine schepen ="); 
OUTINT (nk, 4) ; 
OUTIMAGE; 
OUTTEXT("aantal grote schepen =") ;OUTINT(ng,4) ; 
OUTIMAGE ; 
OUTTEXT("gemiddelde doorlooptijd 
kleine schepen ="); 
OUTFIX(gdk, 3,9) ; 
OUT IMAGE; 
OUTTEXT ("gemiddelde doorlooptijd grote 
schepen ="); 
OUTFIX(gdg,3, 10); 
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IF i>0 THEN 
BEGIN somgemd1t1:=somgemdltitgdk; 
somkwgemd1ti:=somkwgemd1t i+gdk*gdk; 
somgemdlt2:=somgemdlt2+gdg ; 
somkwgemdlt2:=somkwgemdlt2+gdg*gdg ; 
END; 
END; 


PROCEDURE initreportsubrun; 
BEGIN nk:=ng:=0; 

sd1t1:=sd1t2:=0.0; 
END; 


PROCEDURE neumannopslag; 

COMMENT *** opslaan som der doorlooptijden per 
ss per subrun na aanlooprun voor 
berekening von neumann ratio’s ***; 

BEGIN gemdlt1(i):=sdlt1i/nk; 

gemd1t2(i) :=sd1t2/ng; 
END; 


PROCEDURE neumannberek(ss); CHARACTER ss; 
BEGIN INTEGER j,k; 
qt :=qn:=0.0; 
FOR j:=1 STEP 1 UNTIL (nsubr-1) DO 
BEGIN IF ss=’k? 
THEN qth:=gemd1ti(j)- gemdlt1(j+1) 
ELSE qth:=gemd1t2(j)- gemdlt2(j+1); 
qt :=qt+qth*qth; 
END; 
FOR k:=1 STEP 1 UNTIL nsubr DO 
BEGIN IF ss=’k’ 
THEN qnh:=gemd1t1(k)-somgemd1t1/nsubr 
ELSE qnh:=gemd1t2(k)-somgemd1t2/nsubr ; 
qn :=qn+qnh*qnh ; 
END; 
OUT IMAGE; 
OUTTEXT ("waarde von neumann ratio voor "); 
IF ss=’k’ 
THEN OUTTEXT ("kleine schepen =") 
ELSE OUTTEXT ("grote schepen ="); 
OUTFIX(qt/qn, 3, 6); 
END; 
PROCEDURE eindreport; 
BEGIN OUTIMAGE; 
skwgemdlt1:=(somkwgemdlt1- 
somgemdlt1*somgemdlt1/nsubr)/(nsubr-1) ; 
OUT IMAGE; 
OUTTEXT("het gemiddelde van de gem. dlt kleine schepen ="); 
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OUTFIX (somgemdlt1/nsubr,3,8) ; 
OUTIMAGE; 
OUTTEXT("standaardafwijking gem dlt kleine schepen ="); 
OUTFIX (SQRT(skwgemd1ti/nsubr) ,3,8); 
skwgemdlt2:=(somkwgemdlt2- 
somgemdlt2*somgemdlt2/nsubr) /nsubr-1) ; 
OUTIMAGE; 
OUTTEXT("het gemiddelde van de gem. dlt grote schepen ="); 
OUTFIX (somgemd1t2/nsubr ,3,8) ; 
OUTIMAGE; 
OUTTEXT("standaardafwijking gem dlt grote schepen ="); 
OUTFIX (SQRT (skwgemd1t2/nsubr) ,3,9); 

END; 


somgemd1t1:=somgemd1t2:=0.0; 
somkwgemdlt1:=somkwgemdlt2:=skwgemdlt1:=skwgemdlt2: 
=0.0; 
END *** waarnemer ***; 


COMMENT *** hoofdprogramma main initialisatie 
gedeelte ***; 

INTEGER i,nsa, nsubr, nsps, nstop; 

REF (generator) gen1,gen2; 

REF (HEAD) krij ,grij,dummyrij; 

REF (kade) kade1 ,kade2; 

REF (waarnemer) rap; 

krij:-NEW HEAD; 

grij:-NEW HEAD; 

kade1:-NEW kade(’k’ ,krij,grij,1.5); 

kade2:-NEW kade(’g’ ,grij,krij,2.0); 

geni:-NEW generator(’k’,5.5,3,7,876543, 987654) ; 

gen2:-NEW generator(’g’ ,6.7,2,8, 765432, 654321); 

COMMENT *** lezen en opslaan van de lengte van 
de aanlooprun nsa, 
de lengte van een subrun nsps, 
het aantal subruns nsubr ***; 

OUT IMAGE; 

OUTTEXT ("haven oude situatie kbe"); 

OUTIMAGE; 

OUTTEXT(* "); 

OUT IMAGE; 

OUTTEXT("geef lengte aanlooprun"); 

OUTIMAGE; 

nsa:=ININT; 

OUTTEXT("lengte aanlooprun=") ; 

OUTINT (nsa, 5) ; 

OUTIMAGE; 

OUTTEXT("geef lengte van een subrun"); 

OUTIMAGE;. 
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nsps:=ININT; 

OUTTEXT("lengte van een subrun ="); 

OUTINT (nsps ,5) ; 

OUT IMAGE; 

OUTTEXT("geef aantal subruns''); 

OUT IMAGE; 

nsubr : =ININT; 

OUTTEXT ("aantal subruns ="); 

OUTINT (nsubr, 3) ; 

OUT IMAGE; 

COMMENT *** start aanlooprun ***; 

1i:=0; 

nstop:=nsa; 

rap:-NEW waarnemer ; 

rap.initreportsubrun; 

ACTIVATE kadeli; 

ACTIVATE kade2; 

ACTIVATE geni; 

ACTIVATE gen2; 

COMMENT *** wacht op activering vanuit een schip 

(einde aanlooprun) ***; 

PASSIVATE; 

rap.reportsubrun ; 

COMMENT *** uitvoeren van de subruns ***; 

nstop:=nsps; 

FOR i=1 STEP i UNTIL nsubr DO 

BEGIN rap.initreportsubrun; 
PASSIVATE; 
rap.neumannopslag ; 
rap.reportsubrun; 

END; 

rap.eindreport ; 

OUT IMAGE; 

rap.neumannberek(’k’) ; 

rap.neumannberek(’g’); 

END; 
END 


Opmerkingen naar aanleiding van SIMULA programma: 


e [let programma is zodanig opgezet dat gemakkelijk zowel de oude als 
de nieuwe situatie binnen de haven gesimuleerd kan worden. Door de 
uitvoerige parametrisatie van de gedefinieerde processen is het hoofd- 
programma MAIN erg kort en flexibel. Om de nieuwe situatie te kunnen 
simuleren moeten de volgende wijzigingen in het programma worden aan- 
gebracht. 


Uitvoerig simulatievoorbeeld in SIMULA - 7 123 


Met betrekking tot PROCESS CLASS schip: 


oude situatie: 


IF ss=’k’ THEN 

BEGIN wr:-krij; pkss:-kadei; skss:-kade2 END 
ELSE 

BEGIN wr:-grij; pkss:-kade2; skss:-kadei END; 


IF pkss.plaats THEN ACTIVATE pkss 
ELSE IF skss.plaats THEN ACTIVATE skss; 


nieuwe situatie: | 


IF ss=’k’ THEN 

BEGIN wr:-krij; pkss:-kadei END 
ELSE 

BEGIN wr:-grij; pkss:-kade2 END; 


IF pkss.plaats THEN ACTIVATE pkss; 


Met betrekking tot het hoofdprogramma: 
oude situatie: 


kadei:-NEW kade(’k’, krij, grij, 1.5); 

kade2:-NEW kade(’g’, grij, krij, 2.0); 
nieuwe situatie: 

dummyrij:-NEW HEAD; 


kade1:-NEW KADE(’k’, krij, dummyrij, 1.5); 
kade2:-NEW KADE(’g’, grij, dummyrij, 2.0); 


De verschillen tussen de programma’s voor FIFO en KBE 
hebben betrekking op PROCESS CLASS schip: 
FIFO: 


schuit:-wrss.FIRST; 
schuit:-wrnotss.FIRST; 


~schuit:-kortste(wrss) ; 
schuit :-kortste(wrnotss) 


Men had ook met meerdere componentklassen kunnen werken (bijv. 
kadel, kade2, schipg, schipk, generatork, generatorg) waardoor de pro- 
cesbeschrijving per klasse eenvoudiger wordt maar uiteindelijk het gehele 
programma wat minder flexibel. 

e [fet gedrag van de stochastische variabelen kan in beide situaties iden- 
tiek gemaakt worden door gebruik te maken van dezelfde random reeksen 
(startwaarden) van de randomgeneratoren. De waarden van de parame- 
ters Ul en U2, die gebruikt worden als startwaarden voor de randomge- 
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neratoren, zijn willekeurig gekozen. 


e De eindrapportage wordt handmatig gedaan aangezien de t-verdeling niet 
standaard in SIMULA beschikbaar is. 


Stap 11: Proefruns 


Deze stap dient om globaal inzicht in het gedrag van het simulatiemodel te 
verkrijgen om op grond daarvan een ‘definitieve’ serie experimenten te plannen. 

Deze stap wordt opgesplits in vier delen: de opzet van een proefrun, de 
resultaten, de validatie en de evaluatie. 


Opzet 


Omdat we geïnteresseerd zijn in de stationaire toestand kiezen we voor een 
lange run bestaande uit een aanlooprun gevolgd door een aantal subruns van 
gelijke lengte. 

In eerste instantie kiezen we de lengte van de aanlooprun gelijk aan de 
nog te bepalen subrunlengte (zie ook figuur 4.2F en 4.3D). Op grond van de 
berekende bezettingsgraden (voor kade 1 gelijk aan 0.9!) en figuur 4.3D kiezen 
we om te beginnen een subrunlengte van 2000 componenten. (Merk op dat dit 
aantal overeenkomt met een aantal schepen dat in ongeveer een jaar de haven 
aandoet!). Verder wordt gestart met 20 subruns. 


Resultaten 


De resultaten van de hiervoor gespecificeerde proefrun (voor de oude situatie 
KBE) zijn hieronder weergegeven. 

(Alleen de resultaten voor de aanlooprun en de daarop volgende 10 subruns 
zijn afgedrukt). 


haven oude situatie kbe 


geef lengte aanlooprun 
lengte aanlooprun = 2000 


geef lengte van een subrun 
lengte van een subrun = 2000 
geef aantal subruns 

aantal subruns = 20 


subrun 0 

aantal kleine schepen =1096 

aantal grote schepen = 904 

gemiddelde doorlooptijd kleine schepen = 15.251 
gemiddelde doorlooptijd grote schepen = 12.336 
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subrun 1 

aantal kleine schepen =1094 

aantal grote schepen = 906 

gemiddelde doorlooptijd kleine schepen = 
gemiddelde doorlooptijd grote schepen = 
subrun 2 

aantal kleine schepen =1109 

aantal grote schepen = 891 

gemiddelde doorlooptijd kleine schepen = 
gemiddelde doorlooptijd grote schepen = 
subrun 3 

aantal kleine schepen =1099 

aantal grote schepen = 901 

gemiddelde doorlooptijd kleine schepen = 
gemiddelde doorlooptijd grote schepen = 
subrun 4 

aantal kleine schepen =1129 

aantal grote schepen = 871 

gemiddelde doorlooptijd kleine schepen = 
gemiddelde doorlooptijd grote schepen = 
subrun 5 

aantal kleine schepen =1142 

aantal grote schepen = 858 

gemiddelde doorlooptijd kleine schepen = 
gemiddelde doorlooptijd grote schepen = 
subrun 6 

aantal kleine schepen =1108 

aantal grote schepen = 892 

gemiddelde doorlooptijd kleine schepen = 
gemiddelde doorlooptijd grote schepen = 
subrun 7 

aantal kleine schepen =1061 

aantal grote schepen = 939 

gemiddelde doorlooptijd kleine schepen = 
gemiddelde doorlooptijd grote schepen = 
subrun 8 

aantal kleine schepen =1122 

aantal grote schepen = 878 

gemiddelde doorlooptijd kleine schepen = 
gemiddelde doorlooptijd grote schepen = 
subrun 9 

aantal kleine schepen =1089 

aantal grote schepen = 911 

gemiddelde doorlooptijd kleine schepen = 
gemiddelde doorlooptijd grote schepen = 
subrun 10 

aantal kleine schepen =1160 

aantal grote schepen = 640 

gemiddelde doorlooptijd kleine schepen = 
gemiddelde doorlooptijd grote schepen = 


15.479 
13.500 


15.941 
11.820 


16.240 
13.780 


20.869 
14.125 


15.210 
12.565 


14.769 
12.465 


16.419 
12.660 


13.967 
11.436 


14.977 
12.627 


20.578 
14.876 
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het gemiddelde van de gem. dlt kleine schepen = 16.168 


standaardafwijking gem. dlt kleine schepen = 0.749 
het gemiddelde van de gem. dlt grote schepen = 12.672 
standaardafwijking gem. dlt grote schepen = 0.213 


waarde von neumann ratio voor kleine schepen = 1.811 
waarde von neumann ratio voor grote schepen = 2.070 


Vóór het beantwoorden van de vraag van de havendirectie is het gewenst dat 
we in de te vergelijken situaties zoveel mogelijk gebruik maken van gemeen- 
schappelijke randomgetallen. Daarom starten de te vergelijken situaties met 
dezelfde startwaarden voor de randomgenerator. 

Verschillen tussen de te vergelijken situaties worden nu alleen veroorzaakt 
door bewust gekozen waarden van de stuurvariabelen. 

Een overzicht van de resultaten voor de vier te vergelijken situaties zijn 
weergegeven in tabel 7.1 en 7.2. 


FIFO KBE 
oude nieuwe verschil oude nieuwe verschil 
situatie situatie oud-nieuw situatie situatie oud-nieuw 
13,4 11,9 12,3 10,5 | 
15,1 13,2 +1,9 13,5 11,4 +2,1 
12,9 11,7 +1,2 11,8 10,5 ia 
15,5 14,2 +1,3 13,7 12,1 +1,6 
15,2 13,4 +1,8 14,1 11,8 +2,3 
14,1 12,4 bit 12,5 10,9 +1,6 
14,0 12,3 +1,9 12,4 10,7 +1,7 
14,4 16,2 ae 12,6 13,6 jð 
12,5 10,9 +1,6 11,4 9,8 +1,6 
14,3 13,1 +1,2 12,6 11,2 +1,4 
16,8 14,6 +2,2 14,8 12,9 +1,9 
14,2 13,7 +0,5 12,7 11,8 +0,9 
13,2 11,1 +2,1 11,9 9,9 +2,0 
15,4 13,7 $1.1 > Tad 11,8 +1,6 
13,0 10,2 +2,8 11,9 9,5 +2,4 
15,4 14,1 +43 13,0 12,1 +0,9 
12,4 +0,8 11,9 11,0 +0,9 
14,4 +0,2 12,8 12,2 +0,6 
10,3 +2,1 11,2 9,5 betr 
12,4 +0,0 11,4 10,9 +0,5 
1233 +2,5 13,0 10,7 +2,3 


gem.(1-20) 12,8 +1,3 12,6 11,2 +1,4 
q-waarde 2,91 2,07 2,81 


Tabel 7.1: Gemiddelde doorlooptijd grote schepen. (Per subrun in totaal 
(groot+klein) 2000 schepen.) 


Uitvoerig simulatievoorbeeld in SIMULA . 7 127 


FIFO KBE 
oude nieuwe verschil oude nieuwe verschil 
situatie situatie oud-nieuw situatie situatie oud-nieuw 
16,6 26,6 15,2 22,2 
17,1 — 6,9 15,4 20,5 
17,8 —14,7 15,9 25,6 
18,4 —16,9 16,2 29,6 
24,5 —33,2 _ 20,8 39,5 
16,9 —16,9 15,2 32,8 
16,4 —11,9 14,7 23,5 
18,9 —17,8 16,4 29,6 
15,4 BITA 13,9 23,0 
16,8 —5,4 14,9 -18,7 
24,6 —98,8 20,5 72,4 
16,9 —29,6 15,0 57,7 
17,8 —16,4 15,5 27,9 
16,2 —4,6 15,0 17,8 
21,3 —6,2 19,1 51,4 
18,5 —12,0 16,7 26,1 
12,6 —2,6 11,9 13,6 
15,1 —12,1 13,8 22,3 
14,5 —8,6 13,4 19,7 
12,8 —1,3 11,7 12,7 
30,9 —29,0 26,1 44,9 


18,2 —19,8 16,1 30,5 


1,80 1,81 1,65 


Tabel 7.2: Gemiddelde doorlooptijd kleine schepen. (Per subrun in totaal 
(groot+klein) 2000 schepen.) 


Evaluatie en validatie 


Merk allereerst op dat de waarden van de gemiddelde doorlooptijden van de 
kleine schepen met name in de nieuwe situatie per subrun onderling nogal 
verschillen. Dit hangt samen met de zeer hoge bezettingsgraad van kade 1. 

Verder blijkt uit de gepresenteerde resultaten dat de gemiddelde doorloop- 
tijd van de schepen tijdens de aanlooprun (= subrun 0) niet duidelijk afwijkt 
van de overige subrunresultaten. We handhaven dus de gekozen lengte van de 
aanlooprun. 

Binnen de grenzen van het beperkte aantal subruns blijkt dat op grond van 
de gevonden q-waarden (> 1,58) de subruns onderling onafhankelijk veronder- 
steld mogen worden. Daarom zullen we de subrunlengte van 2000 handhaven. 
Door de formules uit hoofdstuk 4 toe te passen vinden we de resultaten uit 
tabel 7.3 (zie volgende pagina). 


Vergelijking van de resultaten uit tabel 7.3 met de analytische resultaten uit 
stap 4 levert de volgende conclusies: 


e Het via simulatie verkregen betrouwbaarheidsinterval voor de doorloop- 
tijd van kleine schepen in de nieuwe situatie met FIFO rijdiscipline omvat 
de analytische berekende waarde (31,3). 
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oude situatie: 
grote schepen: 
nieuwe situatie: 


grote schepen: 


kleine schepen: 


kleine schepen: 


16,2 < 
14,6 < 
13,6 < 
12.9 x 
26,5 < 
233,3 x 
1E 
10,7 x 
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95%-betrouwbaarheidsinterval 
wre Ed) <02 


< 20,2 
< 17,6 
< 14,6 
< 13,0 
< 49,5 
< 37,7 
< 13,5 
zit 


Tabel 7.3: 95%-betrouwbaarheidsinterval voor de doorlooptijden in de 
verschillende situaties. 


e Het via simulatie verkregen betrouwbaarheidsinterval voor de doorloop- 
tijd van kleine schepen in de nieuwe situatie met KBE rijdiscipline over- 
lapt gedeeltelijk het analytisch geschatte interval. 

e Beide voorgaande conclusies gelden ook met betrekking tot de grote sche- 
pen. 

e De gevonden trends in de doorlooptijden van de kleine/grote schepen bij 
overgang van de nieuwe naar de oude situatie stemmen overeen met de 
kwalitatieve voorspelde trends. 


De validiteit van het model voor de oude situatie wordt ondersteund door 
bovengenoemde conclusies (duidend op de validiteit van het model in de een- 
voudigere nieuwe situatie) en het feit dat er een gering en inzichtelijk verschil 
bestaat in het model (programma) voor de twee situaties. 

Met betrekking tot de door de havendirectie gewenste output (dit is het 
verschil tussen oude en nieuwe situatie) vinden we met behulp van de tabellen 
7.1 en 7.2. en de formules uit hoofdstuk 4: 


95%-betr. interval voor verschil in doorlooptijd 
kleine schepen: FIFO: —299 < E(dltoud — dltnieuw) < —9,7 
KBE: —206 < < —8,2 

FIFO: 0,9 < tt A, 
KBE : si GET 


grote schepen: 


Tabel 7.4: 95%-betrouwbaarheidsinterval voor het verschil in doorlooptijd 
tussen de oude en nieuwe situatie. 


Interessant is nu om de resultaten van tabel 7.4, welke gebaseerd zijn op ‘ge- 
paarde subruns’, te vergelijken met het verschil van de subrungemiddelden 
voor elk van de afzonderlijke situaties, af te leiden uit tabel 7.3. 

Met betrekking tot bijvoorbeeld kleine schepen, KBE geldt ruwweg: 
Verschil in doorlooptijd volgens ‘gepaarde’ berekening: 14 + 6 
Verschil in doorlooptijd volgens ‘niet-gepaarde’ berekening: 


(16 + 2) — (30 +7) = 1449 
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We zien dus dat door het ‘paren’ de nauwkeurigheid van het verschil in door- 
looptijden wat toeneemt. 


Stap 12: Definitieve experimenten 


De doelstelling van het onderzoek vermeldt een onnauwkeurigheid van 10%. 


De onnauwkeurigheid van de proefrunresultaten leiden we af uit tabel 
7.4. Bijvoorbeeld voor kleine schepen, KBE geldt een 95% betrouwbaarheid- 
sinterval van 12,4. Stel dat de gemiddelde waarde —14,4 gelijk is aan de 
verwachtingswaarde van het verschil in doorloopltijd. Een onnauwkeurigheid 
van 10% houdt dan in 1,44. Om de betrouwbaarheidsinterval van 12,4 terug 
te brengen tot 2,88 moet het aantal subruns bij benadering gelijk zijn aan 


2 
os .20 = 366. Op overeenkomstige wijze kan ook voor de drie overige 


gevallen van tabel 7.4 het benodigde aantal subruns voor de definitieve expe- 
rimenten worden geschat, waarna de definitieve experimenten kunnen worden 
uitgevoerd. 


Stap 13: Conclusies 


We beperken ons hier tot voorlopige conclusies op basis van de proefrunresul- 
taten. 


Uit tabel 7.3 volgt dat, zoals verwacht, KBE in alle gevallen tot een kortere 
doorlooptijd leidt dan FIFO. 


Uit tabel 7.4. volgt dat de oude situatie voor de kleine schepen qua door- 
looptijd aanzienlijk gunstiger is dan de nieuwe situatie terwijl voor de grote 
schepen in veel mindere mate het omgekeerde geldt. Om op grond hiervan 
tot een verantwoorde beslissing te komen zal een nadere kosten/baten analyse 
noodzakelijk zijn. 


7.4 Opgaven 


1 In een wasserij bevindt zich een wasmachine. Indien de wasmachine klaar 
is met zijn wasprogramma, wordt deze weer gevuld volgens de queuedisci- 
pline FIFO. Dit vullen gaat door totdat er geen wasgoed meer ligt, of 
totdat de maximum capaciteit van de machine (100 kg) overschreden 
wordt als de volgende partij wasgoed toegevoegd zou worden. Blijkt dit 
laatste het geval, dan wordt van het resterende wasgoed onderzocht of er 
nog een of meer partijen mee kunnen. Hierna wordt het wasprogramma 
gestart. Ligt er geen wasgoed meer terwijl de machine nog niet tot 60 kg. 
gevuld is, dan wordt gewacht tot er zoveel wasgoed is aangekomen dat 
deze grens wel overschreden wordt. De (uniforme) gewichtsverdeling van 
de pakketten wasgoed luidt als volgt: 
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30% van de te wassen stukken heeft een gewicht tussen 3-5 kg. 


Met ee 5 Ee Lie ie kk: 
gainer eae $ Lone ie AO — 0%. 
ER : PR eee … 20-30 kg. 


De tijden tussen de aankomsten van partijen zijn negatief exponentieel 
verdeeld met een gemiddelde van 12 minuten. De wastijd (inclusief vul- 
tijd) bedraagt 1 uur. 

De wasbaas zou graag met 95% betrouwbaarheid de gemiddelde door- 
looptijd van het wasgoed en de fractie van de tijd dat de wasmachine 
stilstaat kennen voor een werkdag, waarin de wasmachine 10 keer het 
programma doorloopt. Oo 


In een buurtwinkel komen zaterdags klanten binnen met negatief expo- 
nentieel verdeelde tussenaankomsttijden met een gemiddelde van 3 minu- 
ten. De tijd waarin ze hun boodschappen uitzoeken is uniform verdeeld 
tussen 1 en 6 minuten. Daarna koopt 30% van de klanten vleeswaren 
aan een toonbank. De helptijd hier is uniform verdeeld tussen 1 en 4 
minuten. Alle klanten moeten daarna langs een kassa, waar de helptijd 
negatief exponentieel verdeeld is met een gemiddelde van één minuut. 
De dochter des huizes moet zowel afrekenen bij de kassa als de vleeswaren 
snijden bij de toonbank. Zij verandert van plaats als ze bij de plaats waar 
ze helpt klaar is en bij de andere plaats minstens een persoon wacht. De 
tijd nodig voor het verplaatsen bedraagt een halve minuut. 

Zaterdag is de winkel 9 uur open. 

De eigenaresse van de buurtwinkel vraagt zich af of haar zoontje ook mee 
moet helpen. 

Doorslaggevend voor haar beslissing zijn: 


a de gemiddelde tijd die een klant die geen vleeswaren koopt moet 
wachten, 


b idem voor iemand die wel vleeswaren koopt. o 


In een kapperszaak zijn twee kappers werkzaam, elk met een eigen werk- 
plek en wachthoek waar de nodige lektuur ligt uitgestald. Klanten, die 
eenmaal voor een kapper gekozen hebben, nemen in de desbetreffende 
wachthoek plaats. 

De twee kappers hebben zich ‘gespecialiseerd’. 

Kapper A knipt alleen volgens een ouderwets kapsel. 

Kapper B kan naast het ouderwetse kapsel ook een modieus ‘snel’ kapsel 
knippen. Keuze van kapsel is natuurlijk aan de klant. 

De klanten komen de zaak binnen volgens een negatief exponentiële ver- 
deling. De gemiddelde tussenaankomst tijd bedraagt 14 minuten. 


Van de klanten is 75 procent conservatief en kiest voor het ouderwetse 


kapsel. 
Het knippen van het ouderwetse kapsel kost 4 — 20 minuten (uniform ver- 
deeld). Het knippen van het ‘snelle’ kapsel kost 8 — 12 minuten (uniform 
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verdeeld). Klanten, die langer dan 30 minuten moeten wachten, gaan 
weg. Wanneer beide wachtrijen even lang zijn of beide kappers niemand 
onder de kam hebben, kiest een binnenkomende klant (indien deze van 
een ouderwets kapsel voorzien wil worden) voor kapper A. 

Het betreft hier een ideale kapperszaak, welke dag en nacht geopend is. 


Gevraagd: 95% betrouwbaarheidsintervallen voor de gemiddelde wacht- 
tijd van klanten, voor het ouderwetse en het ‘snelle’ kapsel en het 
aantal weglopers voor beide kapselsoorten. o 


4 In een supermarkt zijn 2 kassa’s; de interaankomsttijden van de klanten 
bij de kassa’s zijn negatief-exponentieel verdeeld met gemiddelde 1 mi- 
nuut. Een klant gaat altijd in de kortste wachtrij staan. Als de wachtrijen 
even lang zijn, of als beide kassa’s zonder klanten zijn, kiest hij willekeu- 
rig een kassa, met gelijke kansen. De bedieningstijd is uniform verdeeld 
tussen 1 minuut en 2.4 minuten. Wanneer op een gegeven moment een 
rij 2 plaatsen korter wordt dan de andere rij ‘switcht’ de laatste klant 
van de langste rij. (De kassieres hebben gemerkt dat veel klanten klagen 
over het lang moeten wachten). De cheffin wil nu graag weten hoeveel 
procent van de klanten langer dan P minuten moet wachten. o 


9 In een dokterswachtkamer komen patiënten binnen volgens een nega- 
tief exponentiële verdeling met een gemiddelde tussenaankomsttijd van 5 
minuten. Dertig procent van de patiënten wachten niet langer dan 10 mi- 
nuten. Tijdens behandeling lopen patiënten niet weg. Wat de tijdsduren 
van de consulten betreft geldt het volgende: 


10% van de patiënten 2 tot 3 min. (uniform) 


BO %.. fs 3 tot 4 min. 
A 35 4 tot 5 min. 
oe. a Š 5 tot 6 min. 
or OE <¢ j 6 tot 7 min. 
o R. 4 7 tot 8 min. 
r S is 8 tot 9 min. 
SN S 9 tot 10min. 


Hierbij zijn niet begrepen de tijdsduren dat de dokter gestoord wordt 
door zijn telefoon. Telefoongesprekken komen gemiddeld om de 6 minu- 
ten binnen met negatief exponentieel verdeelde tussenaankomsttijden. De 
duur van een telefoongesprek is uniform verdeeld tussen 1 en 3 minuten. 
Aanvragen voor telefoongesprekken die vallen binnen een bestaand tele- 
foongesprek, vervallen. De dokter overweegt de aanschaf van een bandop- 
name-installatie voor de telefoongesprekken, daar hij hiermee het aantal 
patiënten dat wegloopt zonder consult hoopt te verminderen. 


Gevraagd: Een 95% betrouwbaarheidsinterval voor het verschil tussen 
de gemiddelde fractie patiënten die wegloopt in de oorspronkelijke 
situatie en die fractie in de situatie met de bandopname-installatie. 

o 
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6 Orders komen aan volgens een negatief exponentiéle verdeling met gemid- 


delde tussenaankomsttijd van 20 minuten en moeten achtereenvolgens op 
machine 1 en machine 2 verwerkt worden. 

De helptijd bij machine 1 is uniform verdeeld tussen 2 en 6 minuten, de 
helptijd bij machine 2 is uniform verdeeld tussen 4 en 6 minuten. Na 
verwerking op machine 1 is er een kans pi, = 0,58 dat de bewerking 
herhaald moet worden. De order moet dan terug naar wachtrij 1 om op- 
nieuw bewerkt te worden waarvoor dezelfde helptijd weer nodig is. In het 
andere geval (p = 1— p11) wordt de order in wachtrij 2 geplaatst. Na ver- 
werking op machine 2 is er een kans po, = 0,33 dat de order terug moet 
naar wachtrij 1. Ook is er een kans poy = 0, 25 dat de order opnieuw door 
machine 2 bewerkt moet worden. De bewerkingstijden blijven hetzelfde. 
Met een kans p = 1 — p21 — p22 is een order na bewerking op machine 2 
klaar. 

De queuediscipline bij de 2 machines is FIFO. 

De bedrijfsleiding zou graag het 95% betrouwbaarheidsinterval voor de 
gemiddelde doorlooptijd van de orders kennen. o 


Hoofdstuk 8 


Uitwerking opgaven 


Opgave 1.3.1 


Wel simulatie: Bijvoorbeeld bij een machine wil men bepalen welke van de 
onderstaande vuistregels gehanteerd moet worden voor het afgeven van een 
levertijd bij orderacceptatie waarbij de verwachte levertijdoverschrijding mini- 
maal is. 


a. levertijd is constant 
b. levertijd is bewerkingstijd + constante 
c. levertijd is bewerkingstijd x constante 


Een verdere uitbreiding van dit probleem, waarbij eveneens simulatie gewenst 
is, is het beoordelen van de levertijdafgifteregels in combinatie met de vol- 
gende twee prioriteitsregels voor het in bewerking nemen van de orders: kortste- 
bewerkingstijd-eerst en vroegste-leverdatum-eerst. 


Geen simulatie: 

e Als de verwachte kosten de verwachte baten ver overschrijden, bijvoor- 
beeld het bepalen van de grootte van de bestelserie van goedkope onder- 
delen met behulp van de Regel van Camp in plaats van met simulatie. 

e Als er onvoldoende gekwantificeerde gegevens beschikbaar zijn, bijvoor- 
beeld bij een supermarkt. Hierin is het ‘erg druk’ bij de kassa’s en men 
overweegt daarom een extra kassa te plaatsen. Indien men niet beschikt 
over geschikte kwantitatieve gegevens met betrekking tot aankomstpa- 
tronen, bedieningstijden etc. en men ook niet bereid is deze te meten is 
simulatie niet zinvol. 

e Als het elementaire situaties betreft waarvoor analytische oplossingen 
bekend zijn. Bijvoorbeeld een loket dat zonder storingen functioneert met 
een Poisson aankomstproces van ‘klanten’ die worden bediend in volgorde 
van binnenkomst met een negatief exponentieel verdeelde bedieningstijd. 


Opgave 2.9.2 


a. variabelen: 
Uitgangsvariabelen: 
e na = aantal aankomsten bij tankstation 
e nd = aantal doorrijders 
e nb = aantal bediende auto’s 
e somwt = de som van alle wachttijden bij het tankstation van de 
bediende auto’s 
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Omgevingsvariabelen: 


e tussenaankomsttijden auto’s bij het systeem 
bedieningstijden bij de pomp 

tijdstippen opengaan spoorbomen 
tijdstippen dichtgaan spoorbomen 


Stuurvariabelen: 
e maximale lengte van de wachtrij bij de tankstation 
Toestandsvariabelen: 


e bo = spoorwegbomen zijn open 

e pv = pomp is vrij 

e ]1 = lengte wachtrij voor spoorwegovergang 
e 12 = lengte wachtrij bij tankstation 


b. conceptueel model: 


aantal, 
auto's in 
systeem 


rijdoor 


systeemgrens 


Vaste componentklassen: wachtrij, overweg, pomp 
Tijdelijke componentklasse: auto 


Uitwerking opdrachten - 8 


activiteit 


wachtrij 


aankomst bij overweg 

in wachtrij voor overweg 
schuif door in wachtrij 

uit wachtrij voor overweg 
passeren overweg 
doorrijden bij tankstation 
in wachtrij bij tankstation 
schuif door in wachtrij 

uit wachtrij bij tankstation 
start tanken 

tanken klaar 

vertrek 

bomen dicht 

bomen open 


activiteitsklasse 


aankomst auto bij overweg 

auto in wachtrij voor overweg 

auto schuift door in wachtrij 

auto uit wachtrij voor overweg 
+ passeert overweg 

auto rijdt door bij tankstati 

auto in wachtrij bij tankstation 

auto schuift door in wachtrij 
tankstation 

auto uit wachtrij bij tankstation 
+ start tanken 

tanken klaar + vertrek 

spoorbomen gaan dicht 

spoorbomen gaan open 


d. 


componentklasse 


veranderingen in 
toestandsvariabelen 


H:=ll l 


l11:=11 — 1 


12:=12 + 1 


12:=12 — 1, 
pv:=FALSE 
pv:= TRUE 
bo:=FALSE 
bo:=TRUE 


overweg pomp 


135 


auto 


Ps 


PA OPS OPS OPS OPS OPS OPS OPS OPS OPS PS 


Wat zijn de eventklassen in ons geval? M.a.w.: door welke gebeurtenissen 
verandert de toestand van ons systeem? (m.a.w: waardoor veranderen de waar- 
den van de toestandsvariabelen bo, pv, 11 en 12 van ons systeem?) 


Antwoord: bij - het opengaan der bomen (bo, 11, 12 en/of pv) o 
- een vertrek (pv en/of 12) 
- een aankomst (11 of 12 of pv) 
- het sluiten der bomen (bo) 


Vv 
a 
S 
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Verbale eventbeschrijvingen (essentieel!) 

Aankomst : Indien spoorweg gesloten gaat auto in wachtrijl staan, an- 
ders passeert auto overweg. Indien de pomp vrij is wordt 
deze bezet, anders wordt wachtrij? één langer, tenzij wacht- 
rij2 daardoor langer zou worden dan p auto’s, dan zal de 
auto doorrijden. 

Vertrek : De pomp komt vrij. Indien er nog auto’s in wachtrij? staan, 
dan gaat de voorste auto uit deze wachtrij naar de pomp. 
De eventuele aanwezige overige auto’s schuiven één plaats 
op in wachtrij2. Indien er geen auto’s in wachtrij? staan, 
gebeurt er niets. 

Bomen sluiten : Bomen gaan dicht. 

Bomen openen : Bomen gaan open. Indien er auto’s in wachtrijl staan, dan 
gaan de auto’s uit wachtrijl achtereenvolgens naar wacht- 
rij2, zolang lengte wachtrij? < p, zodra wachtrij2 > p rijden 
ze door. Indien de pomp vrij is en de eerste auto uit wacht- 
rijl bij wachtrij? aankomt, dan wordt de pomp door deze 
auto bezet, anders wordt wachtrij2 één langer tenzij lengte 
wachtrij? > p: dan rijdt de eerste auto (en alle overige 
auto’s uit wachtrijl) door. 


e. 


Uitgaande van de eventbeschrijvingen en de geformuleerde activiteitsklassen 
vinden we: 


eventkl. waartoe 
act. kl. verandering voorwaarde act. kl mogelijk verandering 
tst. var. op syst. niv behoort omg. var. 
arriveren t= vat a vat:= t+ 
NEGEXP(v,u) 
(tijdstip 
volg. aank.) 


inrijl 11:=11+1 

(schuifdoor) 

uitrij1 li:=l1-1 bo,l1>0 

rijdoor 12>=p 

inrij2 12:=12+1 12<p 

(schuifdoor) 

uitrij2 12:=]12—1 pv,l2>0 vvt:=t+ 

pv:=FALSE UNIFORM (a,b,u) 

(tijdstip 
volg. vertr.) 

vertrek pv:=TRUE 

open bo:=TRUE vst:=t+25 
(volg.tijdst. 
bom. sluit.) 

dicht bo:=FALSE t=vst vot:=t+5 
(volg. tijdst. 
bom. open) 
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(Opmerking kolom 3 en 5 behoren tot een volgende stap die in een later hoofd- 
stuk behandeld zal worden). 


f. 


De stroomschema’s van de eventbeschrijvingen zijn weergegeven in de figuren 


I t/m V. 


aankomst 
begin 


arriveren 


event- 
beschrijving 
aankomst 


event- 
beschrijving 
vertrek 


event- 
eventk lasse beschrijving 
bomen open 


event- 
eventk lasse beschrijving 
d bomen dicht 


aankomst 
einde 
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vertrek 7 II bomen openen bomen sluiten 
begin begin begin 


vertrek 
einde 


e | | rider | 
pompvr ij 
en 
L2=1 
? 


Toelichting op de vijf figuren: 


Fig. I: Globaal stroomschema van de eventbeschrijving. 


Fig. II: Bij de eventklasse ‘aankomst’ is slechts één component van de compo- 
nentklasse auto betrokken. 

Het stroomschema is verkregen door de verschillende activiteitsklassen be- 
horend tot de evenklasse a in de volgorde van tabel e onder elkaar te zetten. 


Fig. III: Bij de evenklasse ‘vertrek’ kunnen 1 tot maximaal p (max. lengte 
wachtrij2) componenten van componentklasse ‘auto’ betrokken zijn. Eén com- 
ponent is altijd de vertrekkende auto. Indien /2 # 0 dan gaat de eerste auto 
uit wachtrij? naar de pomp (begin bediening) en schuiven de overige auto’s in 
wachtrij2 één plaats op, anders is het event ‘vertrek’ al meteen afgelopen. 
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Fig. IV: Bij de eventklasse ‘bomen openen’ is één component van de compo- 
nentklasse ‘overweg’ betrokken; 0, 1, ... componenten van de componentklasse 
‘auto’ (leden van wachtrijl); 1 of 2 componenten ‘wachtrij’ (wachtrijl en/of 
wachtrij?) en één component ‘pomp’. 

Dit stroomdiagram is op dezelfde wijze tot stand gekomen, als figuur II. We 
zien dat de eventklassen ‘aankomst’ en ‘bomen openen’ een groot stuk gemeen 


hebben. 


Fig. V: De enige activiteit die plaatsvindt bij de eventklasse ‘bomen sluiten? 
is het dichtgaan van de bomen. Hierbij is alleen 1 component van de compo- 
nentklasse ‘overweg’ betrokken. 


Opgave 2.9.8 


Het ligt voor de hand storingen (defecten) als een apart soort orders op te 
vatten. Het optreden van een storing komt er op neer dat de bewerkingstijd 
van de order die op dat moment bewerkt wordt met de duur van de storing 
verlengd wordt. Verder is het van belang dat tijdens de bewerking van een 
order er meer dan één storing kan optreden. 


a. Uitgangsvariablelen: nob = aantal orders bewerkt tot nu toe 
somdrlptd = som van de doorlooptijden van de 
bewerkte orders tot nu toe 


Omgevingsvariabelen: vato = volgende aankomsttijd order, 
afhankelijk van de order- 
aankomstsnelheid vo, 

vats = volgende aankomsttijd storing, 
afhankelijk van de storings- 
aankomstsnelheid vs 


Stuurvariabelen: ogbto,bgbto = onder- resp. bovengrens 
__bedieningstijd van order 
ogbts,bgbts = onder- resp. bovengrens 

‘bedieningstijd’ van storing 


Toestandsvariabelen: lwro = lengte wachtrij orders 
VRIJ = machine vrij 
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b. conceptueel model: 


vertrek 


vertrek 


Vaste componentklassen : machine, wachtrij, waarnemer(v/m), aankomst- 
generator 
Tijdelijke componentklassen : order, storing 


C. 


activiteit order storing machine wrs wro ord.gen stor.gen 
Al aankomst order x 
A2 in wro x x 
(AO schuif door) x x 
A3 uit wro + 
naar machine x x x 
A4 start bewerking x x 
A5 einde bewerking 
+ van machine x x 
A6 aankomst storing X 
AT in wrs x x 
(A11 schuif door) x x 
A8 uit wrs + 
naar machine x x x 
A9 start reparatie x x 
A10 einde reparatie 
+ van machine 
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d. 


„Act. klasse verandering in toestandsvar. 
AO 
Al 
A2 lwro:=lwroti 
A3 lwro:=lwro-1 
A4 VRIJ:=FALSE 
A5 VRIJ: =TRUE 
A6 
ÀT IF VRIJ=FALSE THEN 
lwrs:=lurs+i 
A8 lwrs:=lwrs-1 
A9 mach(ine)stand:="B" 
A10 mach(ine)stand:="V" 
All 


Act. klasse Componentklasse 
ogen sgen wro wrs machine order storing 
AQ x 
Al x | 
A2 
A3 
A4 


A5 
A6 
AT 
A8 
A9 
A10 
A11 


f. Stroomdiagram 


Het stroomdiagram staat op de volgende pagina. 


Opgave 4.5.1 

Geen duidelijke aanloopverschijnselen door lage bezettingsgraad. Daardoor 
r i 

X1 —r) = 0,5 en bij- 


behorende beperkte wachttijd en doorlooptijd snel bereikt ook bij het starten 
vanuit een leeg systeem. 


wordt de overeenkomstige korte gemiddelde rijlengte 
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Opgave 4.5.2 


Lage bezettingsgraad: Systeem is dan regelmatig leeg. Hierdoor wordt de toe- 
stand van het systeem op willekeurig moment niet sterk beïnvloed door de 
toestand die een langere tijdsduur hieraan vooraf ging. Aangezien een leeg 
systeem als ‘ontkoppelpunt’ kan worden opgevat resulteert dit in een korte 
subrunlengte. 


Hoge bezettingsgraad: Systeem zelden leeg. Gemiddelde rijlengte groot. Er 
treden weinig ‘ontkoppelpunten’ op. Toestand van het syteem sterk beïnvloed 
door voorafgaande toestanden gedurende een relatief lange periode. Dus hoge 
subrunlengte om ‘onderlinge onafhankelijkheid’ te bereiken. 


Opgave 4.5.3 


Het herhalen (met andere randomgetallen) van runs die steeds starten van- 
uit een leeg systeem waarbij het ‘aanloopdeel’ (waarvan de lengte nog nader 
bepaald moet worden) niet in de meting wordt meegenomen. 


Opgave 5.5.2 


Maximaal toegestane waarde van p is gelijk aan de arraygrootte waarin de 
aankomstmomenten worden opgeslagen, in dit geval 100. 


Opgave 6.8.2 


BEGIN 
COMMENT stuurvariabelen; 
INTEGER p; COMMENT inlezen maximale aantal wachtpl. op het 
emplacement ; 
OUTIMAGE; p:=ININT; COMMENT inlezen waarde p; 
BEGIN 
COMMENT hulpvariabelen; 
BOOLEAN stopprogram; 
REAL inf; COMMENT oneindig; 
INTEGER u; COMMENT startwaarde randomgenerator; 
INTEGER maxauto; COMMENT aantal auto’s per subrun; 
REAL ARRAY rij2(1:p); 
COMMENT omgevingsvariabelen; 
REAL v, a, b, vat, vvt, vst, vot; 
CHARACTER ek; COMMENT eventklasse; 
COMMENT toestandsvariabelen; 
INTEGER 11, 12; 
BOOLEAN bo, pv; 
COMMENT uitgangsvariabelen; 
REAL somwt; 
INTEGER na, nd, nbediend; 


144 


COMMENT proceduredeclaraties; 
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PROCEDURE klok; COMMENT bepaling tijdstip en type van 


BEGIN 
COMMENT t=min(vat, vvt, vot, vst); 
IF vat<t THEN BEGIN ek:=’a’; t:=vat; 
IF vvt<t THEN BEGIN ek:=’v’; t:=vvt; 
IF vot<t THEN BEGIN ek:=’o’; t:=vot; 
IF vst<t THEN BEGIN ek:=’s’; t:=vst; 
END; 


PROCEDURE naarp; 
BEGIN INTEGER i; 
somwt :=somwt+t-rij2(1); 


eerstvolgende event; 


vat:=inf; END; 
vvt:=inf; END; 
vot:=inf; END; 
vst:=inf; END; 


12:=12-1; COMMENT opschuiven resterende auto’s in 


wachtrij2; 


vertrek; 


ð IF 12>0 THEN FOR i:=1 UNTIL 12 DO rij2(i):=rij2(i+1); 
pv:=FALSE; 
vvt :=t+UNIFORM(a,b,u); COMMENT tijdstip eerst volgende 
END; 


PROCEDURE gatanken; 
BEGIN 
11:=11-1; 
IF 12>=p THEN nd:=nd+1 
ELSE BEGIN 
12:=12+1; rij2(12):=t; 
IF 12=1 AND pv THEN naarp 
END 
END; 


COMMENT initialisatie; 
v:=.25; a:=2.0; b:=5.0; 
11:=0; 12:=0; 


-bo:=pv:=TRUE; stopprogram:=FALSE; 


somwt:=0.0; na:=nd:=nbediend:=0; 
vat :=NEGEXP(v,u); 


vst:=25; COMMENT bij begin simulatie zijn bomen juist 


inf :=10*#99; u:=918273; maxauto:=500; 
vvt:=vot:=inf; 
t:=inf; 


COMMENT simulatie; 
WHILE NOT stopprogram DO 
BEGIN klok; 

IF ek=’a’ THEN 


open gegaan; 
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BEGIN 
na:=nat1; 
vat :=t+NEGEXP(v,u); 
11:=11+1; 
IF bo THEN gatanken; 
END; 
IF ek=’v’ THEN 
BEGIN 
pv:=TRUE; 
nbediend: =nbediend+1; 
IF 12>0 THEN naarp; 
END; 
IF ek=’o’ THEN 
BEGIN 
bo:=TRUE; 
vst:=t+25; 
WHILE 11>0 DO 
BEGIN 
gatanken 
END 
END; 
IF ek=’s’ THEN 
BEGIN 
bo:=FALSE; 
vot:=t+5; 
END; 
IF (nbediend + nd) = maxauto THEN stopprogram:=TRUE; 
END; 
COMMENT druk resultaten af; 
END; 
END 


Opgave 6.8.8 


Componentklasse Classtype Reden 

waarnemer CLASS geen ‘driehoek’ of ‘rondje’ in 
procesbeschr. componentklasse, 
geen wachtrij, 


geen wachtrijelement 
wachtrij HEAD wachtrij 
machine PROCESS CLASS ‘driehoek’ en ‘rondje’ in 


procesbeschr. componentklasse 
aankomstgenerator PROCESS CLASS ‘rondje’ in procesbeschr. 
componentklasse 
order LINK CLASS geen ‘driehoek’ of ‘rondje’ in 
procesbeschr. componentklasse, wel 
wachtrijelement 


storing LINK CLASS idem 
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Het SIMULA programma: 


BEGIN SIMULATION BEGIN 

CLASS waarnemer; BEGIN ......... END; 

PROCESS CLASS N: BEGIR Irisa i END; 

PROCESS CLASS aankgen(type,iai,ogbt,bgbt,u) ; 
CHARACTER type; REAL iai, ogbt, bgbt; INTEGER u; NAME u; 
DMEM. viesta E END; 

LINK CLASS order(bt);. REAL bt; BEGIN .........s. END; 

LINK CLASS storing(duur); REAL duur; BEGIN ........ END; 


REF (waarnemer) marlies; REF (m) mach; 

REF(HEAD) wro, wrs; 

COMMENT activeren vaste componenten; 

marlies:-NEW waarnemer; wro:-NEW HEAD; wrs:-NEW HEAD; 
mach:-NEW m; ACTIVATE mach; 

ACTIVATE NEW aankgen(’o’ ,6.5,5,10,123456) ; 

ACTIVATE NEW aankgen(’s’ ,48,10,20, 789012) ; 

HOLD (480); COMMENT simulatie betreft 1 werkdag van 8 uur; 
marlies.rapport; 

END 


Uitwerking van de diverse componentklassen: 


LINK CLASS order(bt); REAL bt; COMMENT bt=bewerkingstijd; 
BEGIN 
REAL at; COMMENT aankomsttijd at is nodig voor het 
bepalen van doorlooptijd dlt; 
at:=TIME; INTO (wro); 
IF wro.CARDINAL = 1 AND mach.vrij THEN ACTIVATE mach; 
END; 


LINK CLASS storing(duur); REAL duur; 
BEGIN 

IF mach.vrij = FALSE THEN INTO(wrs); 
END; 


PROCESS CLASS m; COMMENT machine; 
BEGIN BOOLEAN vrij; REF(order) job; REF(storing) stor; vrij:=TRUE; 
WHILE TRUE DO 


BEGIN 
IF wro.CARDINAL = 0 THEN PASSIVATE; 
vrij:=FALSE; 
WHILE wro.CARDINAL > 0 DO 
BEGIN 


job:-wro.FIRST; job.OUT; 
HOLD(job.bt) ; 
WHILE wrs.CARDINAL > 0 DO 
BEGIN 

stor:-wrs.FIRST; stor.OUT; 
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HOLD (stor.duur) ; 
END; 
marlies.drlptd(TIME-job.at) ; 
END; 
vrij :=TRUE; 
END; 
END; 


PROCESS CLASS aankgen(type,iai,ogbt,bgbt,u) ; 
CHARACTER type; REAL iai, ogbt, bgbt; INTEGER u; NAME u; 
BEGIN 
WHILE TRUE DO 
BEGIN 
HOLD (NEGEXP (iai,u)) ; 
IF type = ’o’ THEN NEW order (UNIFORM(ogbt ,bgbt,u) ) 
ELSE NEW storing(UNIFORM(ogbt,bgbt,u)) ; 
END; 
END; 


CLASS waarnemer; 
BEGIN REAL somdrlptd; INTEGER nob; 
PROCEDURE drlptd(dlt); REAL dlt; 
BEGIN 
nob:=nobt1; somdrlptd:=somdrlptd+dlt ; 
END; 
PROCEDURE rapport; 
BEGIN 
OUTIMAGE; OUTTEXT ("Gemiddelde doorlooptijd orders: "); 
IF nob > 0 THEN OUTFIX (somdrlptd/nob,2,10); 
ELSE OUTTEXT ("geen verwerkte orders") ; 
END; 
nob:=0; somdrlptd:=0.0; 


END; 
ES i ARIES Benin hen bete een OS Eh ARENT E RT a 
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